Jump to content

Igors

Private
  • Content Count

    865
  • 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. 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.
  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 soluti
  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 un
  5. Igors

    Memory

    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

    Memory

    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 th
  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. 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 ma
  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
  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" =
×
×
  • Create New...