If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Exciting News: Chaos acquires EvolveLAB = AI-Powered Design.
To learn more, please visit this page!
New! You can now log in to the forums with your chaos.com account as well as your forum account.
nice speedup im interested to see what happens in physically very large scenes.. if i understand things correctly the limited precision available might manifest itsself as problems of some kind, more in big scenes. however its doubtful if i actaully -do- understand things so ho-hum. hopefully ill have time to test myself soon.
ok so i tried it (non avx version) on a giant masterplan scene with 45,000 trees and 1500 sq km of buildings. rendertime without: 8:07, rendertime with embree and the various tree types, between 7 mins 40 and 7 mins 50. one domelight in the scene.
so not a huge improvement in this case, and im not sure where or what to look for any errors... renders look the same to the naked eye.
be interesting to render a test anim, but no time at the mo.
my rig is an i7 920 at 3.8 with 24 gb ram. vray 2.30.01, max 2012 sp2 x64.
Works VrayEmbree with CPU Intel I7 920 and os WinXPx64?
The plugin is not loaded in max2010: "Error Loading DLLs:<C:\Program Files .....................\vrayembreee2010.dlo> failed to inizialize. Error code 127
hmm you think its advisable to change the default geometry type to static? it already uses all 24 gig of ram in my system.. i thinkif it treated the 45000 instanced trees as copies i might have issues..
is it a big job to adapt the embree system to work with dynamic geometry? i cant remember the last scene i did that didnt rely heavily on instancing and proxies..
Dynamic geo is in general slower (not being part of the main bsp/bvh tree).
I think the idea of having it all static is a VERY good one in general if performance is an issue, and i can see why the BVH methods (which is based on bounding volumes' hierachies) don't, and won't work (in a performing way, ofc) with proxies or dynamic geo which still today obey the BSP rules (in the case of proxies, it's a binary space partitioning embedded in the file format, and for dynamic geo it's still a BSP built on the fly and discarded when not needed. Am i correct here, Vlado?).
It's more than a tack-on change, by any stretch of the imagination, even from a user's perspective...
Comment