Igors

Thanks, thinking...

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:)

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

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

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

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

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:

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.

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

Hello Dave No probs to get your code, just mail us your dongle

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

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:

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:

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)

Hello Michael Please upload project

Hi All Yes, it's a common problem as Ian noticed. Motion blur requires vertices positions at previous frame, but there is no appropriate way to get them with child cycling.

Hello Nige It's a typical room scene. Create Area lights for windows, setup their quadratic dropoffs and photon params. Use more photons (like 2 millions per light). Turn GI off (for a while), specify "Always Visible" map mode. Play with map settings until you get a draft illumination you like. It's 3/4 of all work, the rest is easy: turn GI on and set mode "GI & Secondary". But don't hurry with final render, take care of good photon illumination first. Good luck

Hello Spleeve Sorry for delayed answer (been hardly busy last days). The link is interested but, for concrete example, EI caustics uses RT only partially. Half or more of caustics calcs is made with Z-buffer just because it's faster. So in this context a hardware acceleration would not be very effective. Speaking of GPU and hardware render overview - it looks interested and promised but IMO can be considered only after standard/common resources (such as RAM. processors) are fully used and utilized. First basic, then advanced

Hello Richard, James, All Sure, a fast reply is always wanted/better. But not everyhing can be answered quickly. It was better for us first to check how it works and where is the prob. We remember this request from Daniel (2007) and from Jens (2009). Hmm... "The life is a long song" :rolleyes:

Hello James, All We realize it's a reasonable request, but its eventual implemention is not near easy. The details are: - as you know, buffer shadow is a (simplified) render pass that should be written in ccn file. - for a local render the Animator writes shadow pass for first frame and a shadow file reference for all further frames, so all is fine. Note that Animator also removes shadow file(s) before render starts. - in network render every frame (or strip) is written in separated ccn to be distributed over network in any order. Slave Cameras could not know either given frame first or last, it's just "render job" for them. Thus shadow pass(es) should be written in any ccn and should be processed by slave Cameras anytime. Also it's unclear how to check existed shadow file consistence and how to avoid numerous obsolete files on slave's side. All that does not mean "impossible", IMO it can be added for UserPack voting, we just explained why it's a solid portion of work.

Hello Richard Thx for the prj. It looks like PPPro problem, it crashes if attached child group hides its own child(ren). Test steps: - add MrBlobby to prj (just default settings) - link your "Walker" (or any other model) to MrBlobby - now link MrBlobby to PPPro. Try to open plug-in's interface. Crash.

Hi, Richard Please add CrashReport file too

Hello Brian 1) In host you can export a sequence of FACT files (although we're not sure about motion blur) 2) As we've understood "Renderama mode" is an optional feature. Try to turn it off, remove all temp files and render with Rama. Yes, it forces more calculations but it can be acceptable. 3) About "shame". From our experience a support of temp files is really hard (espeially in view of distributed render). For "Parametric Surface" plug-in we could not support animation at all because it required in several times more work. Universal solution in host (baking, "Gnome") was proposed in 2006, then in 2008. No luck yet. Ok, "The life is a long song" :rolleyes:

Hello Bill Thx for the detailed info. Generally all is quite expected, for our taste image looks interested. Ok, a discussion of art nuances is not our affair, so speaking technically: - more photons. Although you can fill room very fast with relative small amount, it's not always a best. Millions and millions of photons = a normal practice in any app. - sometimes it's helpful to use less radii value(s). Although it makes a more blotched map overview, edges/corners are more accurate - and it's better for final GI - standard approach is to render several baked maps and compare/analyze these images

Hi again CFM = "Code Fragment Manager". Why "PPC CFM", not just "PPC"? Because PPC specifies hardware (kind of processor) only. CFM makes clear that is an old format (not Universal Binary) of application. You can run UB app on PPC as well. We played with Dante31 a little (EI8 Intel Mac). Yes, if "Renderama Mode" = on, then nothing does work as Michael said. Obviously this mode is intended to calculate all particle once ("baking" in fact) but anyway it's optional. We're not sure the created file is used at all if "Renderama Mode" is off. It makes a sense to keep it off, remove all temp files and test. At least without Rama we see everything is Ok and plug-in is fully functional. We didn't notice API-specific problems (although they are possible).