Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

38 Excellent

About Igors

  • Rank
    Posting Freak

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hola Diego It's a pipeline limitation, specuars of GI lights are unachievable for "illuminator" shaders like MForge. Setting "Use GI Sampling engine" tells render to calculate this light in GI pass and store illumination in GI buffer fоr further interpolation. If a material has highlight shaders (such as Anisotropic) their specular will be calculated for each ray. However there is no way to do same for MForge because it takes a whole control over material and can be called only once per (sub) pixel. Well, "nothing is perfect" (banal but true :shy:)
  2. Igors

    Speed comparison

    Hi All Here are some tech explanations. About render speed: EI8 simply used "brute force" with RT reflections/refractions. For example a pixel with reflective material is shaded. With default AA 4x4 there are 16 initial reflection rays. For every ray hits something - do calc GI there. With default "GI secondary = 50" we've 16 * 50 = 800 rays. With mutual and/or blurred reflections this amount becomes huge because rays' propagation is kinda "chain reaction". So brute force provides quality, but with inacceptable slow render time. That's why EI9 uses principally new techniques for this. About hardware preview Yes. hardware "phong" preview is faster in EI8 because it was not "phong" there :shy: (same "gourand" with limited abilities). EI9 provides true hardware phong preview using OpenGL shaders. In other words EI8 shaded "every vertex", but EI9 "every pixel" in this mode Generally a task "better speed and quality" has no limits, simply it should be better and better in any new version of app
  3. Hello Brian Plugins are not multithreaded because only plugin itself knows what to do. Host also can't do other things before geometry is fully created. But there are no obstacles for developers to write multi-threaded plugins. A render time difference 32/64 is normal/expected in this case. When 64-bit render core calls 32-bit plugin a some time is wasted to switch between 64/32 and back. With intensive exchange (1.5 millions) the render times difference is noticeabe. With smaller geometry it's less. You need native 64-bit version of the plugin. Using 32-bits plugins is a temporary solution before Animator is moved to 64-bit
  4. Hello gentlemen We saw how Tom repulsed your persistent attacks ;), now we've a minute to say few words 1) ETA is always a problem. We see no one lucky example. Remember EIM (Tesla) promised im March 2007, but where is it? Ok, so why EI9 is so long? There are 2 reasons why a) Every development plan is approximate at start, there are always things to solve on road, it's normal/unavoidable. A perfect/ideal/academic plan would never work in practice. Foe example: Rama bugs in EI8. Yes, it took several months and increased our timeline a lot. But what to do? Do not fix it? User will be unhappy (btw: same user who asked about fastest release). Same with GI, Camera Maps and many other - after learning prob in all details there is much more work than expected. We guess same in your art projects. b ) Second reason is just one word "re-architecturing". Many things in EIAS was designed really cool, and even now, many years later, we see no better solutions. Same time a lot is obsolete and should be re-designed, It's a normal process of evolution for any software. Yes, architecture changes do not produce immediate result always but they are necessary, otherwise we've no room for concrete final features for user. This aspect was ignored in prev EI versions and with EI9 we've got an effect of "awaken dog" Well, it's our first release, we guess from now things would go easier and faster ;) 2) A promised full features list and (especially) public beta = a very risked venture (said softly). Or, in simple words it can kill product. We've learned effect of public beta - and for us it was totally counter-productive. User's appetite has no limits It's normal, but a great minus of public beta is: user momentary forgets about done things (really, they are already in his pocket, because promised). Instead his attention is concentrated on things he would like to see. Typically these ideas are quite rational but.. they should be matured, analyzed and implemented in next round of development. So we think only base/flag features (like MP/64 in EI9) should be announced before. Any release should be a holiday/surprise. :) That's all, thx for your understanding
  5. Igors


    Hi, Brian You're right and it's a common prob for plugins that create a large geometry. We'll think how to solve this. but nothing is promised (be honest no one idea is in our heads yet) Thanks
  6. Igors


    Hello, Brian, All Animator 9 still will be 32-bit app, with 2Gb RAM barrier. However it's important to understand that 64-bit is not a "magic wind" to solve all RAM problems: - we've no doubts Brian always can create so dense mesh that's impossible to place into his 18 Gb (right?) room. Appetite has no limits. - before to create such meshes it's a good idea to think what to do then in Animator, how long they can be previewed etc. - can't say about Placer but BlobMaker and Mrs do use obsolete memory allocation approach and thus can't be ported to 64 immediately. Changing the approach would allow to use twice more RAM even in 32-bit. - and the last one: Hmm... it looks like Camera is just a small (unsignificant) detail, huh? :rolleyes:
  7. Hi All Let us add some explanations EITG was the publisher of the Konkeptoine products. They did not have ownership or source code. EIAS3D is now publishing many of these products, but it is up to the original owner of each of the products to decide if they wish to continue to support them. We are more than happy to publish 3rd party products on our web site and are eager to work any and all 3rd party developers.
  8. Hello fiberblast Of course 16/32 render is needed, but we think with 2Gb RAM limit it would be not very effective, cause such images eat significantly more memory. Therefore others features should be done first. Note: RPF_Saver has "non-clamped color" channel (32 bits) that can be used for post-processing
  9. Hello Dave No probs to get your code, just mail us your dongle
  10. Igors


    Hello Brian Because FACT stores all info in vertices. FACT simplest cube has 24 vertices (3 per each corner). If we need different vertices normals at corners/edges, we must create extra vertices with same positions but different normals. Same with UV seams
  11. Hello Nigel About edges/corners blotching a) increase (baked) photon map quality as possible b) if you use "Light Customize" - do this only as "final polishing", it would be interested to see the image without any customize (if possible) About contact shadows. As we see the shadows are enough dark/contast but glass objects look "fly off". The attachment is an approximate glass material setup (just for our taste). Of course you need to use subtractive color filter for colored transparent objects. Also: if there is an ability to make the round table a bit less transparent - it could make life easier. Because "transparent on transparent" - where a shadow comes from? :rolleyes:
  12. Hello Nigel Speaking technically this photon map is quite acceptable. Blotching is not dangerous because anyway GI averages collected reversed illumination. Bake the map (if it's not baked yet). Edges and corners should not be darker. Of course, more shadows or less etc - all this for artist/taste, it's controlled by lights' intensity, dropoff and bouncing settings. About transparency artifacts. First off check them with only simple light with shadows. If Ok, check photon maps settings (should be "GI & secondary". If nothing could help - please simplify prj and upload to BugsTracker here :rolleyes:
  13. Hi All 1) About test project: if we consider 10 things together, so most probably no one problem will be found :rolleyes: Thus we've simplified prj, there are 2 lights: Light Object (white quad)) and RT light (no soft shadow, visible red spot in reflections). Both do emit photons 2) Quadratic dropoff should be set for lights with photon emission. Otherwise photon map can be far away of direct/GI illumination. Although Area Lights (and Light Objects) can be used without such dropoffs, it does not produce correct results and usable "as is" 3) Walls planes were made with "Cast Shadow" = off. Here it gives no speed advantages, but kills photons' bounces (if an object casts no shadow, so photons should pass thru as it's a fully clipped surface, isn't it?) 4) The attached image shows reflections calculated fast (just use photon maps) and fully (rays count = 50 for both: GI and Area Light). Sure that fast reflections are less accurate but they can be usable (especially for blurred ones)
  • Create New...