PDA

View Full Version : Instancing LW 9.5?



roger1972
07-27-2007, 11:25 AM
Is there any hope seing instancing in LW9x rendercore this year? this is just the little thing I want for this package. I look on exterior-animations rendered in 3DS-MAX Vray, and they have billions of polygons ecosystem rendered. Is this something that LW is going to add to the core or do I really have to buy a copy of MAX, VRAY and OKINO polytrans to get this thing? And I'm not going to use HDInstance since it's 2-4 times slower than LW, and it does not support Fprime.

Is there some inside information out there, just to give me some hope?

papou
07-27-2007, 11:45 AM
HD_instance is 2-4 times slower than lightwave but not on comparative things.
You just can't add so much polygons in lightwave. You have to parse and parse and parse again, and it can take long time too. just my 2 cents...

I like the way HD_instance work. I would like to see it improved. I will like to see some native instance in lightwave too...

Don't have any info about LW9x futures.

roger1972
07-27-2007, 12:50 PM
What do you do in this case if you have 50 million instanced polygons?

don't think that would be a problem if fprime should support instancing...
Fprime render HW, and that's no problem?

Bytehawk
07-27-2007, 01:19 PM
I just hope that instancing will not require the amount of memory to render to keep each individual model in memory.

ie : 1 trees = 10 x the amount of memory as if you rendered one tree

roger1972
07-27-2007, 01:31 PM
just found an image rendered with vray, prob. Onyx tree and instancing...
http://tirad.com/gallery/02_007h.htm

pixym
07-27-2007, 01:46 PM
héhé,
I had seen a making of from renderfarm.ru prooving that one of their scene is composited... I don't know for this one, but compositing is used. Just see combustion among the used softwares.
BUT, the composited mid-scenes that take part of the whole scene are very BIG if you talk about amount of poly that had to be generated with Vray Proxies.
The rendering is also not very fast because of the amount of polys.
AND this studio is called "Renderfarm.ru" and they have a "small" renderfarm that you can see on their web page.

pixym
07-27-2007, 01:49 PM
Papou is right to talk about HD Instance about the rendering time for the same thing...

nthused
07-27-2007, 01:55 PM
just found an image rendered with vray, prob. Onyx tree and instancing...
http://tirad.com/gallery/02_007h.htm

:agree: Images like that make me extremely frustrated at LW's inability to instance.

roger1972
07-27-2007, 01:57 PM
héhé,
I had seen a making of from renderfarm.ru prooving that one of their scene is composited... I don't know for this one, but compositing is used. Just see combustion among the used softwares.
BUT, the composited mid-scenes that take part of the whole scene are very BIG if you talk about amount of poly that had to be generated with Vray Proxies.
The rendering is also not very fast because of the amount of polys.
AND this studio is called "Renderfarm.ru" and they have a "small" renderfarm that you can see on their web page.

when it comes to using Lightwave native render for this thing with HD-I, you just can't sit waiting 30 hrs. pr frame rendering if you have 2000 frames to render... we use a 25 computers in a farm to render, and we use fprime to do it... so my conclusion is if NT had put instancing native in lw, we could have fprime supporting this and we could render these movies at 2hrs pr frame instead.

roger1972
07-27-2007, 02:00 PM
:agree: Images like that make me extremely frustrated at LW's inability to instance.

that's just the last thing I need to make insane ext. movies... then LW is complete for my use...

Sensei
07-27-2007, 02:14 PM
when it comes to using Lightwave native render for this thing with HD-I, you just can't sit waiting 30 hrs. pr frame rendering if you have 2000 frames to render... we use a 25 computers in a farm to render, and we use fprime to do it... so my conclusion is if NT had put instancing native in lw, we could have fprime supporting this and we could render these movies at 2hrs pr frame instead.

Good to dream.. ;)
If NewTek implements instancing it will for 99% of chances not be available for 3rd party plug-ins like it's now with real motion blur or GI.. FPrime can do it's own instancing without waiting for LW instancing, like it's with KRay..

If you want instancing with fast interpolated GI - better don't even dream about it - it would eat tons of memory for each instance GI cache data.. Only non-interpolated GI would work fine without using a lot of memory with it..

roger1972
07-27-2007, 02:23 PM
Good to dream.. ;)
If NewTek implements instancing it will for 99% of chances not be available for 3rd party plug-ins like it's now with real motion blur or GI.. FPrime can do it's own instancing without waiting for LW instancing, like it's with KRay..

If you want instancing with fast interpolated GI - better don't even dream about it - it would eat tons of memory for each instance GI cache data.. Only non-interpolated GI would work fine without using a lot of memory with it..

But Fprime uses LW's renderengine? it renders HW? so you are saing that fprime is a renderengine that just takes geometry from lw openGL and render it? and if this is right I should start writing on the fprime forum instead?

Sensei
07-27-2007, 02:32 PM
But Fprime uses LW's renderengine? it renders HW? so you are saing that fprime is a renderengine that just takes geometry from lw openGL and render it? and if this is right I should start writing on the fprime forum instead?

1. FPrime does not use LW render engine.
2. FPrime does not use HardWare (if that's what you meant) graphics card for acceleration.
3. FPrime does not take geometry from LightWave's OpenGL! It takes it in LW Master Plug-In, probably double buffers it (copies to it's own memory, so LW can alter, delete it, without crashing FPrime), and render on 2nd and more custom FPrime threads independently from LW.. Using LW just for texturing (procedural textures and nodes).

RedBull
07-27-2007, 03:02 PM
Yes even with native instancing in LW, having it accessible by third parties has always been LW's issue. So even if NT implement it, FPrime would not have access, and would require an update even if it could.

What's more of a problem is making Instancing work between Modeler and Layout... I mean ideally we need to make instances in Modeler that can be instanced in Modelling, which will work in Layout.. (al'a Modo)

HD Instance is great, but volumetric instancing does have some limitations..

alifx
07-27-2007, 03:52 PM
Good to dream.. ;)
If NewTek implements instancing it will for 99% of chances not be available for 3rd party plug-ins like it's now with real motion blur or GI.. FPrime can do it's own instancing without waiting for LW instancing, like it's with KRay..

If you want instancing with fast interpolated GI - better don't even dream about it - it would eat tons of memory for each instance GI cache data.. Only non-interpolated GI would work fine without using a lot of memory with it..

8~ , thanks for the info sensei

that means it's impossible to make a real instances like other programs in lightwave?


hmmm... is LW cursed by something :|

Sensei
07-27-2007, 04:18 PM
No, of course instances are possible in LW! I just said that roger1972 should not count on that FPrime will use it.. He is not using LW native renderer, so LW instances won't be useful for him..

alifx
07-27-2007, 04:36 PM
hehehe
sorry, lost my focus! I'm very tired for now.. I had had alot of work today.


going to sleep now hehe
thanks again brother ^_^

Pavlov
07-27-2007, 06:46 PM
if LW instancing will be volumetric, it's not unprobable fprikme will render it, and HD-I too.
By now remember we have Kray. Though HD-I placing looks much more comfortable, placing nulls for Kray instances is a breeze with CloneFamily... i'm rendering a 1200 trees scene with instances and i'll do a movie, frametime looks around 2-3 min on my 8core.
Kray is going to allow full volume rendering, so it's not unprobable we'll be able to render HD-I instances in Kray... that will be a beautiful day ;)

bye
Paolo

pixym
07-27-2007, 07:06 PM
mmm, if lw instance will be volumetric, I don't see no more reason to go on using HD Instance...
But the more options we will have, the more happy we will be :D

Mark The Great
07-27-2007, 07:19 PM
This is slightly off topic, but what all has NT promised for the 9 series? Link?

prospector
07-27-2007, 08:19 PM
CA....supposidly the most advanced animation since God made Adam with only 2 polygons.

Instancing..where trillions of trees with millions of leaves could be rendered in under 30 min per frame.

That's what I read someplace but forgot where so I have no links to it. :D

geothefaust
07-27-2007, 08:50 PM
It's funny this comes up. I've been finding myself needing instancing more and more lately.

I hope it's similar to XSIs. It's pretty darn good.

Silkrooster
07-27-2007, 10:10 PM
CA....supposidly the most advanced animation since God made Adam with only 2 polygons.

Instancing..where trillions of trees with millions of leaves could be rendered in under 30 min per frame.

That's what I read someplace but forgot where so I have no links to it. :D
This brings up a point I was going to ask. Instancing theoretically should render faster than the same scene created with geometry, correct?
Silk

nthused
07-27-2007, 10:41 PM
This brings up a point I was going to ask. Instancing theoretically should render faster than the same scene created with geometry, correct?
Silk
Not necessarily. Instancing allows us to render almost unlimited polygons in a scene. While it would be a great bonus if it rendered faster - it's not a given.

Silkrooster
07-28-2007, 12:26 AM
Hmmm. My thought is the renderer would only have to raytrace a single object not a 1000 objects and then calculate the differences if possible.
Silk

jin choung
07-28-2007, 02:07 AM
actually, all this talk about instancing sounds off to me for some reason.

sounds like it's being made up to be more than it is.

instancing (i.e. 1000 x a single object) would only require A SINGLE DESCRIPTION OF THE OBJECT (geometry, materials, etc) but file size even on disk goes up more than the scene with just the one object because you have to have TRANSFORMATION VECTORS (transform node in maya) for every instance.

so you have 1 object description and 1000 transform vectors when you load it into ram.

BUT

when you RENDER, whether it is to the screen via opengl or to your rendered bitmap, raytracing or scanlining STILL has to calculate as if there are 1000 objects in the scene.

it still has to figure out where the light is in relation to EVERY NORMAL of EVERY POLY of EVERY OBJECT (actually, that's only for a 1990s video game... you'd be doing PER PIXEL calcs for a software render). and that's JUST LIGHTING. and the transform stage of rendering still has to figure out where all the geometry is in space to draw it before that... then you got the boatload of other calcs that still have to be done on each instance to render it.

so yah, it buys you SOMETHING.... but i can't imagine that it is instancing alone that is allowing other renderers to fly. maybe they got other things going on with dicing a scene up with oct trees or bsps, smart occlusion culling, distributed rendering, better multithreading... but it can't all be instancing.

jin

jin choung
07-28-2007, 02:19 AM
oh, as for unlimited polygons...

instancing would do ZERO for you if you wanted to render a single character model that had a billion polygons.

so there's a law of diminishing returns.... if you have a "MASSIVE (tm)" scene with millions of 100poly guys who are 20 pixels high running around in the bg, then you can easily load that into memory.

if you have a scene with 10 unique characters with ridiculous poly counts, you get nothing.

jin

jin

jin choung
07-28-2007, 02:28 AM
http://features.cgsociety.org/story_custom.php?story_id=3889

we should integrate that CPU GEMS tutorial !!!

it's a commercially available book they can buy for $50 and it lets you do some awesome detail culling! why calculate 1000 polys that are going to end up being a single pixel?!

in my mind, "instancing" is certainly not end all be all.

jin

roger1972
07-28-2007, 02:55 AM
oh, as for unlimited polygons...

instancing would do ZERO for you if you wanted to render a single character model that had a billion polygons.

so there's a law of diminishing returns.... if you have a "MASSIVE (tm)" scene with millions of 100poly guys who are 20 pixels high running around in the bg, then you can easily load that into memory.

if you have a scene with 10 unique characters with ridiculous poly counts, you get nothing.

jin

jin

I want to render 5000 trees and maybe 20000 grasspatches....

trees with 200.000 polys and grass... Now I can't do that... but with instancing i could do that...

jin choung
07-28-2007, 03:04 AM
again,

i don't know that instancing is the end all be all, magic bullet solution to doing massive renders.

all the issues that i mention are relevant to it.

sure, maybe you would be CAPABLE of making a render with that many trees and patches of grass with instancing, but maybe not very fast.

so if your desire is to render all that stuff and do it quick and do it well, i think just communicating that need and not focusing on instancing alone as the magic solution would be more prudent to your cause.

but just my opinion. ask for what you please.

jin

alifx
07-28-2007, 03:04 AM
renders that were taking 12 or 13 hours went down by a factor of three to four. We got the same or better results in a quarter of the time.

that technique would make rendering super fast if it integrated.

but what do LW programmers say about it?


yeah, is there a list?
not a list but if you scroll down you find some info about that.
http://www.newtek.com/lightwave/faq/

for Instancing Netek said this

Will LightWave v9 have instancing?
Instancing will be added in a later update in the v9.x cycle. We'll be making the core changes that will allow us to provide instancing immediately as our first effort after the release of v9.0. These same changes to the core operation of LightWave will fix a number of long-standing issues in the code and provide the basis for a complete change in the workflow of the application, including a variety of other long-requested capabilities such as history, parametric evaluation, scene graph and more.

AbnRanger
07-28-2007, 05:25 AM
I want to render 5000 trees and maybe 20000 grasspatches....

trees with 200.000 polys and grass... Now I can't do that... but with instancing i could do that...
This is where Vue 5/6 comes into the picture...because it can handle these kinds of demands without alot of hassle.

Sensei
07-28-2007, 06:08 AM
3D packages that use bucket rendering can handle much larger amounts of polygons, due to the bucket segmentation and not needing the entire scene geometry in memory at the same time.

That's true for very simple scenes, when you don't have occlussion, GI, refractions and reflections, SSS.. Otherwise rays hitting such surfaces might be redirected to areas that are not calculated yet, and causes them to be calculated and put it in KD-Tree.. Then, if they are cleared after rendering 1st bucket, you might end up with re-calculating them many many times in the next buckets.. On the other hand, if you leave them in memory, you might end up with out of memory..

Lightwolf
07-28-2007, 06:21 AM
On the other hand, if you leave them in memory, you might end up with out of memory..
That's why they usually have a very good memory management ;)
Also, secondary rays usually do not need the geometry displaced at such a high resolution, so there is plenty of room for improvements with some clever coding.

Cheers,
Mike

Captain Obvious
07-28-2007, 06:34 AM
I once rendered a few billion polygons in modo, using instancing. It was kind of neat seeing its FPrime-like interactive previewer render all that. :)

Instancing saves a lot of memory. If you have clones of an object, and the geometry is exactly the same, instancing lets you render pretty much an infinite number of them.

Pavlov
07-28-2007, 07:05 AM
Vue is really not an option. You need WAY too much workarounds and very costly software (Xtream + an insane licensing per node system) to get it working into Lw and it's awfully slow.
Instancing is not an option, we need a rock solid tool into LW. HD-I looks nice but no Fprime, no full GI compatibility, no GI caching are major limits.
Let's see what time brings... hoping that it's just *a little* time ;)

Paolo

pixym
07-28-2007, 07:13 AM
Vue is really not an option. You need WAY too much workarounds and very costly software (Xtream + an insane licensing per node system) to get it working into Lw and it's awfully slow.
Instancing is not an option, we need a rock solid tool into LW. HD-I looks nice but no Fprime, no full GI compatibility, no GI caching are major limits.
Let's see what time brings... hoping that it's just *a little* time ;)

Paolo

Paolo, Yes Vue is not an option an awfully slow as I notice in a previous thread.
http://www.newtek.com/forums/attachment.php?attachmentid=48280&d=1184772151
The same scene renders in less than 2min without Vue...

pixym
07-28-2007, 07:20 AM
Edit of the previous post:
Vue is awfully slow INSIDE LW via Xstream...
It is what I noticed while testing the PLE version.

hrgiger
07-28-2007, 08:41 AM
Sure, I might expect instancing from Lightwave 9.5. It seems like a ".5" feature for sure. But whether I would actually expect 9.5 this year is a whole other issue (I don't). Maybe a .3 or .4 or something though and that's still a maybe.

prospector
07-28-2007, 06:15 PM
Maybe a .3 or .4 or something though and that's still a maybe.

must have confidence......must have confidence

sammael
07-28-2007, 10:12 PM
Dont know how I missed this thread, instancing is the feature I want above ALL else and have for years. Stop talking about HD instance because we need instancing native to LW period.

roger1972
07-29-2007, 03:17 AM
I once rendered a few billion polygons in modo, using instancing. It was kind of neat seeing its FPrime-like interactive previewer render all that. :)

Instancing saves a lot of memory. If you have clones of an object, and the geometry is exactly the same, instancing lets you render pretty much an infinite number of them.

I was looking at modo 301, and it is going to support animations... then I just import my LWS into modo and render exterior animations from modo instead... then I have the solution for my tree instancing problem... :)

archijam
07-29-2007, 04:37 AM
:agree: Images like that make me extremely frustrated at LW's inability to instance.

MAX can't instance without VRAY.

j.

jin choung
07-29-2007, 04:45 AM
no? isn't there an option when you duplicate to actually duplicate or instance?

it's been a while but i seem to remember something like that.

jin

archijam
07-29-2007, 04:58 AM
Geometry intancing yes (cloning etc), but not render optimised instancing.

I agree with your comments in one regard Jin - if they are for a still image. often it's just far easier to use workarounds, in any program.

But for an animation, instancing is a must, it's much harder to fool the human brain when movement is involved ..

j.

dmack
07-29-2007, 05:04 AM
I have done exactly that - tree instancing with HD Instance. It worked an absolute treat. About 60,000 trees with poly counts of around 60,000. I'm not convinced that HD instance renders 3-4 times slower - I've never really noticed a slow down when using it. It seems ot take no time to sort the polies or move the geometry and that alone on multi-million scenes saves significant time!

I agree that LW could do with completely integrated instancing (with time offsets and LOTS of placement options) but for now, HD Instance offers a fabulous solution that has a proven production track record. My fear is that newtek produce an instancing version worse than HD instance and that because it's there, it kills HD Instance development.

Instancing, to me, it is utterly essential. I couldn't do half of my projects efficiently without it. The alternative is a whole load of comping - no thanks! Instancing is something that Newtek should take VERY seriously and by that I mean they should implement it as a fully featured, fully integrated and rock solid set of tools - not something banged together quickly to claim they have have 'instancing' - that would be a tragedy!

jin choung
07-29-2007, 05:44 AM
Geometry intancing yes (cloning etc), but not render optimised instancing.


see, this is the thing that needs to be clarified.

when i hear instancing, all i hear is "geometry instancing". that is ALL i hear. description of the geometry and its materials need not be duplicated. only transforms.

anything else in the notion of "render optimized instancing" seems to speak of other technologies. NOT instancing.

i'd really like to know what the nature of this "render optimized instancing" that you guys seem to be so enraptured with would be.

anyhoo, as others have pointed out, if you're doing anything but scanline rendering - if you're doing ray tracing and all of its children (ambocc, radiosity, etc.), an instance is just as THERE and needs to be calculated for as any "original".

jin

Captain Obvious
07-29-2007, 10:59 AM
I was looking at modo 301, and it is going to support animations... then I just import my LWS into modo and render exterior animations from modo instead... then I have the solution for my tree instancing problem... :)
Well, you'd have to create an MDD and import that into 301. You can't just load an LWS and get all the animations. It does seem to work quite well, though.

Captain Obvious
07-29-2007, 02:48 PM
The instancing in HD Instance is a lot more limited than the one in modo 301. It is easier to create TONS of instances with it, though, since you can use geometry as a base. There are quite a few differences.

Pavlov
07-29-2007, 04:19 PM
Modo's instancing looks interesting, any link ?

Captain Obvious
07-29-2007, 05:57 PM
Just try the trial version, why don't you? Really, it's quite basic. Imagine that you have the Clone functionality from Layout, except it creates instances instead. That's pretty much what it is. Oh, and it works with rail clone and array and stuff like that as well, which is neat.

nthused
07-29-2007, 06:27 PM
Loved this video showing a quick forest creation in Modo. Hopefully, LW will implement something similar. Very cool

http://www.cgbeard.com/main/main_pages/tutorial_2.html

It's the 2-minute forest.

gaushell
07-29-2007, 06:31 PM
Speaking for us - if Lightwave doesn't get things like instancing and GI working properly soon, we will be joining the ranks of Modo or similar -

and I've been using Lightwave for nearly 15 years!

It is way overdue - HDInstance is not an acceptable solution. Modo 301 looks very promising. Time for Newtek to be more forward with the community on their plans.

Sensei
07-29-2007, 07:01 PM
Loved this video showing a quick forest creation in Modo. Hopefully, LW will implement something similar. Very cool

http://www.cgbeard.com/main/main_pages/tutorial_2.html

It's the 2-minute forest.

Do you see render frame statistics window where is written that there is 4 million polygons and 8 million vertices... ? It's in mega bytes, or it's element count?

Nicolas Jordan
07-29-2007, 08:20 PM
I will be disappointed if native instancing is not included as part of the next Lightwave release. I don't feel so demanding asking for it when instancing already appears in a 3D package that costs slightly less than Lightwave. Instancing was on the original development road map so I am hoping that it hasn't been set on the back burner.

roger1972
07-30-2007, 01:07 AM
Now of course if you've already got Modo, then that's great. If you haven't, why spend THAT kind of money when HD Instance is so much cheaper and you don't have to import into another app? $895 as opposed to $145. And HD also comes in a 64bit version. Just curious.

I tried modo 203, I instanced 120 trees from vue, rendered with Montecarlo GI, 7 minutes rendertime on 640x480... I pay $1000 for that ANYTIME!!!

Lightwolf
07-30-2007, 01:15 AM
It's in mega bytes, or it's element count?
Element count.

Cheers,
Mike

Trulsi
07-30-2007, 03:05 AM
see, this is the thing that needs to be clarified.

when i hear instancing, all i hear is "geometry instancing". that is ALL i hear. description of the geometry and its materials need not be duplicated. only transforms.

anything else in the notion of "render optimized instancing" seems to speak of other technologies. NOT instancing.

i'd really like to know what the nature of this "render optimized instancing" that you guys seem to be so enraptured with would be.

anyhoo, as others have pointed out, if you're doing anything but scanline rendering - if you're doing ray tracing and all of its children (ambocc, radiosity, etc.), an instance is just as THERE and needs to be calculated for as any "original".

jin

Yeah, I am wondering about this to. Is it just a 2,5d compositing thing in disguise?

jin choung
07-30-2007, 03:35 AM
i would just like some literature or some sourcing about why people think that an instance requires any less calculation time than the original during render....

jin

Captain Obvious
07-30-2007, 06:38 AM
i would just like some literature or some sourcing about why people think that an instance requires any less calculation time than the original during render....

jin
It doesn't. But it does require a hell of a lot less bandwidth, meaning it can still render faster (since it will be less held back by memory access). Also, creating the space partitioning is a lot faster with instancing, since it'll just create ONE tree for the base object, and then do bounding boxes for the instances (at least, this is how it seems to work in most renderers that do it).



Here's an interesting example. It looks awful, but it serves to illustrate a point. 950 million polygons. I can't remember the render time, but it wasn't too bad.http://www.modonize.co.uk/Simon/grass.jpg

jin choung
07-30-2007, 10:50 AM
ah, thanks. right.

so it's as i expected. and if your app doesn't do space partitioning, then you're still gonna be in the land of waiting forever....

which is my point. it seems more beneficial to ask for what you need (render tons of stuff) rather than ask for a SINGLE bullet point of a raft of features that you need to get what you want.

jin

Captain Obvious
07-30-2007, 12:15 PM
ah, thanks. right.

so it's as i expected. and if your app doesn't do space partitioning, then you're still gonna be in the land of waiting forever....

which is my point. it seems more beneficial to ask for what you need (render tons of stuff) rather than ask for a SINGLE bullet point of a raft of features that you need to get what you want.

jin
Are there actually renderers that don't do space partitioning?

Instancing that works in FPrime would solve an unbelievable number of issues we're having, though.

jin choung
07-30-2007, 02:07 PM
well, you do space partitioning for the sake of OCCLUSION CULLING... figure out who's not being seen by rays and then dropping those bad boys out of calculation.

ummmm... actually, i'm not sure LW has any kind of mechanism to cull out such extraneous detail.

jin

Lightwolf
07-30-2007, 02:17 PM
well, you do space partitioning for the sake of OCCLUSION CULLING... figure out who's not being seen by rays and then dropping those bad boys out of calculation.

ummmm... actually, i'm not sure LW has any kind of mechanism to cull out such extraneous detail.

Erm, it does, that's what the KD-tree - added in 9.0 - does.
And technically LW always used a mechanism for occlusion culling when raytracing - if just a simple and clumsy one - called bounding boxes.

Cheers,
Mike

Captain Obvious
07-30-2007, 02:45 PM
A little bird whispered in my ear that an early beta of FPrime 3 actually rendered HD-Instance. Of course, it still used HD-I's slow ray tracer for all the instances, so there wasn't much of a speed benefit, compared to Lightwave. And I guess it was unstable or buggy or something as well, since it wasn't there in the final version.

There's really no reason why FPrime would be unable to render instances. Being able to render a billion polygons in FPrime would result in spontaneous massive joygasm.

bjornkn
07-30-2007, 03:05 PM
I love HD-Instance, and with LW9.2 the render speed is quite acceptable for my projects, so there's not really that neccessary to render in FPrime any longer. Some of the new nodes looks strange/bad in FPrime too, like Sigma.
But OTOH HD-instance doesn't support nodes at all (yet, but soon - hopefully).
But I certainly woudln't be unhappy if we got native instancing in LW :)
I use SketchUp a lot for modeling, and instancing there really helps things speed up a lot! It's just very handy to model one window and then let all the rest of them be instances. When you need to change all of them you just change one of them - and all get updated automatically. You wouldn't be able to do that in Layout alone, because when a window changes its size it will leave a hole in the wall.
I think that for instancing in LW to be really useful, like in SU, we need to get one application with Modeler and Layout combined - which is my main wish for v 9.5. Keeping them as 2 separate programs is IMHO one of the main reasons why the development is rather slow..

jin choung
07-30-2007, 03:32 PM
hey mike,

really? cuz we have absolutely no controls exposed to us in regards to occlusion... and when it comes to things like ray tracing and radiosity, even if it's not in the shot, it can contribute to the render solution (i.e. reflected diffuse energy or just a plain old reflection).

so how does it figure out what to occlude? and if it takes into account the possibility of being included in the solution, NOTHING would get culled anyway.

i guess the test would be to have a scene with a million dealies on a hill. render.

then drop a simple cube room with no windows around your camera and render. render.

(in this case, there could be no possible affect of the dealies on the final render)

would there be a difference in render time? cuz now, with the room in place, if occlusion culling is being done and done right, the render time should drop as if you were only rendering the cube.

jin

Lightwolf
07-30-2007, 03:44 PM
hey mike,

really? cuz we have absolutely no controls exposed to us in regards to occlusion... and when it comes to things like ray tracing and radiosity, even if it's not in the shot, it can contribute to the render solution (i.e. reflected diffuse energy or just a plain old reflection).

so how does it figure out what to occlude? and if it takes into account the possibility of being included in the solution, NOTHING would get culled anyway.

The occlusion culling (as you call it) is more or less an early rejection test for rays hitting geometry.
In the simple case: if a ray doesn't hit the bounding box, it won't hit what's inside - in the case of a kd-tree, if it doesn't enter a part of the (disected) scene space, it won't hit what is inside of that either.
Which in the end means less geometry to check for potential intersections.

Technically, occlusion culling is a bit different though, it basically defined a technique to not take invisible geometry into account. Raytracing (by definition) does that more or less automatically to a large extent (especially with single sided polygons - polygons facing away from the ray are culled for that ray for example).


i guess the test would be to have a scene with a million dealies on a hill. render.

then drop a simple cube room with no windows around your camera and render. render.

(in this case, there could be no possible affect of the dealies on the final render)

Hardly any with the kd-tree, not counting the pre-processing (actually creating the kd-tree).
A bounding box algorithm fails miserably here, since the bounding box of the room is intersecting with the bounding box of the dealies (unless they are separate meshes, in which case they'd have their own bounding boxes).


would there be a difference in render time? cuz now, with the room in place, if occlusion culling is being done and done right, the render time should drop as if you were only rendering the cube.

Not quite that far, but it will.

This is why it could be advantageous in previous releases of LW to split up large (in terms of covering a lot of area) meshes into smaller sections, to increase the number of bounding boxes (only when raytracing).

With the kd-tree, LW will divide the "world" to be rendered into spaces by using planes (X, Y, Z axis aligned) - depending on the amount of geometry within the spaces it will continue to do so (checking for intersection against planes is fairly speedy). the nice thing is that this takes all geometry into account at once, this is why high poly meshes raytrace a lot faster now (as compared to LW 8.x and earlier).

Cheers,
Mike *phew*

jin choung
07-30-2007, 09:34 PM
The occlusion culling (as you call it) is more or less an early rejection test for rays hitting geometry.
In the simple case: if a ray doesn't hit the bounding box, it won't hit what's inside - in the case of a kd-tree, if it doesn't enter a part of the (disected) scene space, it won't hit what is inside of that either.
Which in the end means less geometry to check for potential intersections.

Technically, occlusion culling is a bit different though, it basically defined a technique to not take invisible geometry into account. Raytracing (by definition) does that more or less automatically to a large extent (especially with single sided polygons - polygons facing away from the ray are culled for that ray for example).

...

*phew*

hey mike,

phew indeed :).

actually, i disagree with your 'refinement' of the definition for occlusion culling. occlusion culling is NOT concerned with invisible geometry in every sense. it's not concerned with a face whose normal is aimed away from camera (backface culling) or objects outside the camera frustrum (frustrum culling... more than one kind of culling out there).

in either case, space partitioning is superfluous.

i am indeed talking about culling(dropping) stuff from render calculation as a result of OCCLUDERS as determined by shooting rays.

i think i represented the issue accrately.

but i didn't remember the stuff about lw having kd trees and never new about the bounding box stuff.

and yes, i am indeed talking about occlusion techniques that are MORE AGGRESSIVE than the stuff done simply through the process of ray tracing... that take advantage of space partitioning that someone brought up.

so again, basically, i'm saying instancing alone is not the magic bullet. it needs to be in conjunction with other technologies.

jin

jin choung
07-30-2007, 09:47 PM
oh, re: millions of dealies, i'm assuming all the dealies are separate objects and the room is also a separate object.

i would be curious to see how much difference there is in render time.

it would be nice if we had agressive render optimizations that would drop the dealies early such that the render saving is substantial.

jin

Sensei
07-31-2007, 01:24 AM
i would be curious to see how much difference there is in render time.

Who cares what would be speed if it would just don't work with transparent objects and half advanced nodes and materials.. ? At geometry preparation stage, geometry should not be removed from calculations because it's unknown what is their surface and surrounding surfaces which might direct rays to hit this geometry, that for the basic look might look as never hit by rays like for example box inside box..

f.e. implementing KD-Tree in TrueHair in currently rendered scenes that have approximately 1-20 million equivalent polygons speeduped rendering 6500 times to what would be if there is no KD-Tree and there is simple ray->all hair guides intersection routine one by one..

jin choung
07-31-2007, 02:07 AM
Who cares what would be speed if it would just don't work with transparent objects and half advanced nodes and materials.. ? At geometry preparation stage, geometry should not be removed from calculations because it's unknown what is their surface and surrounding surfaces which might direct rays to hit this geometry, that for the basic look might look as never hit by rays like for example box inside box..


right... and that is a concern that i've mentioned several times already. when you raytrace, you have to take into account objects that may not be "obviously" or technically in shot but contribute to the final render solution.

clearly, i am not advocating a system that increases speed while introducing bad renders.

the issue is whether the notion of instancing alone allows for good/fast rendering of tons of crap or whether there are necessary attendant technologies that need to accompany it to get the desired feature (good fast crap).

jin

Lightwolf
07-31-2007, 02:19 AM
actually, i disagree with your 'refinement' of the definition for occlusion culling. occlusion culling is NOT concerned with invisible geometry in every sense.
You are right, it was the wrong term to start off with.


i am indeed talking about culling(dropping) stuff from render calculation as a result of OCCLUDERS as determined by shooting rays.

But that is something raytracing does automatically... with more or less efficiency.
In raytracing, any polygon that is hit before another one is automatically an occluder. It might be brute force, but that is why space partitioning schemes are used (as you mention below as well).


but i didn't remember the stuff about lw having kd trees and never new about the bounding box stuff.

and yes, i am indeed talking about occlusion techniques that are MORE AGGRESSIVE than the stuff done simply through the process of ray tracing... that take advantage of space partitioning that someone brought up.

space partitioning = kd-tree (which is superior to octrees for example).
As sensei mentions, anything that actually removes geometry is potentially dangerous due to surface properties... unless geometry can be dynamically added back to the scene during the render process (or is evaluated lazily - on demand - during the render). However, the latter is very hard if you don't use buckets.

Bounding boxes were in LW for ages (and the optimizations I mentioned made a huge difference back then). Remember the "Extra Ray Trace Optimization" button in LW 8.x? That for example created tighter bounding boxes (tighter due to mesh deformations/translations in the scene transforming the simple bounding boxes as well).


so again, basically, i'm saying instancing alone is not the magic bullet. it needs to be in conjunction with other technologies.

Yeah, but these we have already (unless we go into displacements which open up another can of worms)

Cheers,
Mike.

jin choung
07-31-2007, 02:56 AM
Yeah, but these we have already (unless we go into displacements which open up another can of worms)


howdy mike,

okidoke. thanks. that clarifies things. we have everything (except bucket rendering/lazy data handling) that would make instancing speed up large renders... ? hmmm....

then that brings me back to - what is it about instancing, in the sense that people are referring to it here - results in improved render performance (apart from the fact that something can be rendered at all - which i get)?

i know instance as simply a way of reducing file size (on disk/in memory) of the scene description... not something that is relevant to render.

cheers,

jin

Lightwolf
07-31-2007, 03:50 AM
then that brings me back to - what is it about instancing, in the sense that people are referring to it here - results in improved render performance (apart from the fact that something can be rendered at all - which i get)?

Nothing except for the reason you mention.

It might be that the preprocressing is a tad bit faster (less geometry), but that doesn't make much of a difference.
Also, a lower memory footprint may speed up access to datastructures a tad bit (depending on the CPU cache etc...), on the other hand, instances may also be a tad slower to evaluate.
A lot of this depends on the actual implementation.


i know instance as simply a way of reducing file size (on disk/in memory) of the scene description... not something that is relevant to render.

Well, if it allows you to render scenes you couldn't render before I'd say it is relevant to rendering as well ;)

Cheers,
Mike

Pavlov
07-31-2007, 04:15 AM
Let's open it, current displacement implementation is weak for too many tasks and i really hope we will have something better - i.e not relying on high polycounts and subpatches.
What would be needed to implement an industry-standard-compliant subpixel displacement into LW by now ?

Paolo

Lightwolf
07-31-2007, 04:31 AM
My guess is that it's impossible without a bucket renderer.
Certainly not impossible... but a lot harder to do efficiently.

Cheers,
Mike

ben martin
07-31-2007, 04:36 AM
Vue is really not an option. You need WAY too much workarounds and very costly software (Xtream + an insane licensing per node system) to get it working into Lw and it's awfully slow.


Paolo, Yes Vue is not an option an awfully slow as I notice in a previous thread.
http://www.newtek.com/forums/attachment.php?attachmentid=48280&d=1184772151
The same scene renders in less than 2min without Vue...

I don't disagree that Lightwave should have a good instance engine.
Unfortunately I completely disagree about Vue being much slower inside Lightwave or not and option.

I was part of Vue beta test team for some years and I'm a very happy user of Vue xStream 6 and Lightwave 9 with perfect results.
Let me clarify.

xStream plug-in integrates the best of two worlds (Lightwave render engine and Vue Render engine) inside Lightwave Layout. Meaning:
The Vue ecosystems is rendered using exclusively the Vue render technology and the Lightwave objects are rendered using Lightwave render technology in the same scene.
What the xStream plug-in does is simply to calculate and sync Cameras, Lights, Shadows, Reflections, Motion Blur and some other volumetric elements to integrate these elements booth directions in the two render engines scene; this method allows a kind of real time composition between boot render engines.

Sure that if the Lightwave objects are all chrome, it will take a little more to Lightwave to render the Vue scene landscape reflected maps in you Lightwave chrome objects or the Lightwave objects reflected in the Vue water surfaces or chrome objects but that is all about it!

I intensively tested this render times comparison (pure Vue scene stand alone render vs. xStream Lightwave integrated) and I can assure that if you are obtaining such bad results when integrating xStream and Lightwave you guys are doing something terrible wrong.

Other well known issue is that people usually miss concept about Vue render quality options selection.
Vue can be used to two different major works:
Matte/print visualization and Motion Graphics.

To matte or print visualization increasing all parameters almost to maximum including more DPI per render will result at insane render times (but doesn't all the other application do that?)

When it comes to Motion graphics you only need to choose Broadcast quality render preset and then do some tweaks to obtain the quality you need for most of demanding motion renders.

There is one point to keep in mind though:
Avoid to choose Volumetric/Spectral atmospheres (if you don't need to fly trough the clouds), GI environment, volumetric lights if you really don't need such items in your scenes!
Use global or standard atmospheres instead and let Lightwave calculate volumetric lights but keep in mind that volumetric lights or FX always requested large amounts of time and memory even in Lightwave native scenes! Don't expect Vue miracles on this!

You can see the attached:
This is a fast test scene I did especially to illustrate the integration xStream/Lightwave.
The ship is a Lightwave object and the Landscape is only Vue.
I did not use many instances like grass and small plants, only large palm tree and some ferns.
This was rendered using xStream and it took in about 4m25s.
Five min. per frame can be considered much time to some people but it depends on the CPU or render-farm you have available. This demonstrative test was rendered in a Pentium-4 running at 3,2Ghz -1GbRAM.

ILM can't be that wrong about integrating Vue xStream on their software pipe-line, not to talk about my team and many other teams/freelancers around the world!

Its good when people share and discuss about the problems they find and do positive exchange of experiences/feedback but just don't assume things just because you heard someone telling this or that.
Even if you tested any software and the results were not the ones you were expecting, always consider that you can be doing something wrong.
I always assume such specially if it's the first time I'm trying a software application!

Hope this could help to clarify some misconceptions though I 200% agree that Newtek should consider a powerful instance engine integrated in Lightwave but first please consider a good and practical CA tool studio.


Many thanks for reading

Pavlov
07-31-2007, 05:09 AM
Ben, thanks for the infos.
I admit i have been not clear, i said: "You need WAY too much workarounds and very costly software (Xtream + an insane licensing per node system)"
The workaround part is *if you use Vue + Lw without Xstream*, so using old-school methods like passes and so on.
*very costly software and insane licensing per node* is referred to Xtream instead. I never tried it, but even if i'm pretty sure results can be excellent, pricing per node is imho way high, i should spend many thousand euros to use my farm with it.
So actually these were two different issues ;)

Paolo

Pavlov
07-31-2007, 05:36 AM
damn-edit-time.
Anyway: i'd be curious about full GI rendering timing in Xtream, if E-on changes radically its licensing i could consider it.
By now, imho, a good solution to get instancing+GI+cache for animation is Kray. This scene has more than 1200 trees/shrubs and it render pretty fast, i'll give more percise infos because these were just first tests and i didnt keep track of times. Please dont look at poor design, its a preliminary phase and movie is needed just to describe urbanization. As said, i'm curious to know average time/frame with full GI in Vue for a similar scene.

Paolo

jesusguijarro
07-31-2007, 07:25 AM
damn-edit-time.
As said, i'm curious to know average time/frame with full GI in Vue for a similar scene.

Paolo

I have made this one in Vue and it tooks 11' 20'' in a AMD 4400.

Pavlov
07-31-2007, 07:54 AM
nice, but trees fill only a small part of the pic. Can you try to do a pic with the same average % of vegetation than mine, with an AA which doesnt flicker in animation, and at PAL rez ?

thanks,
Paolo

vpii
07-31-2007, 08:23 AM
Pavlov saw your post and made fast test here just now. Loaded old project into Vue and painted some trees and rendered. took about 5 min to setup scene and took 11min and 38 seconds to render. I set full GI to make comparable test with broadcast settings. also forgot 154 million polys

Pavlov
07-31-2007, 09:31 AM
Very interesting... gonna try it better since i got VUE in 9.0 update. I have vue 5, not latest one... which one are you usign in this test, and which machine are you using ?

thanks,

Paolo

vpii
07-31-2007, 09:48 AM
This was done in 6 xstream. It is faster now but the big thing is now you paint your plants down real time. Before in 5 you did not have as good as control over your landscape. The link between lightwave now is more stable.
I am using a duel opteron 4400.

vpii
07-31-2007, 09:55 AM
ps look at this site if you are intersted in examples of vue. This guy does alot of the marketing for VUE

http://www.belino.net/

ben martin
07-31-2007, 10:12 AM
damn-edit-time.
Anyway: i'd be curious about full GI rendering timing in Xtream, if E-on changes radically its licensing i could consider it. As said, i'm curious to know average time/frame with full GI in Vue for a similar scene.

Paolo

Pavlov,

I set up this scene in 5 minutes to mimic a "kind of" city surrounded by trees.
By the way… I did not setup lights or any other render details - just rendered and go!

I did two test renders.
One is not GI, gess the one is not. :)

CPU specs - Intel Pentium 4 - 3.2Ghz - 1Gb

Global scene detail:
1.272.783.488 polygons
68.347 trees

No GI Render time: 00:13:27s
GI Render time: 01:07:05s

Take into account the computer specs it was used and the number of polygons present in the scene.

I recommend that you test the software yourself and make your conclusions.
http://www.e-onsoftware.com/products/?page=try

If you need any tip or advice fell free to ask!

Pavlov
07-31-2007, 10:19 AM
Ben - It's just pricing, otherwise Xtream looks pretty good.
Vpii - If you dont have to deal with non-friendly ecosystems setup (another thing i really hate in Vue), it can be even more interesting.. gonna give it a better look, thanks.

Paolo

roger1972
08-01-2007, 06:57 AM
anyone made animations with Vue Xstream?

vpii
08-01-2007, 07:21 AM
I have played with it a bit, very strait forward. Using the Lightwave plugin you can setup camera moves then render in Vue if your more comfortable. Vue for speed you can adjust alot of your GI controls till you get acceptable image quality. Once you get a good mix in the panel you can save it out as an enviroment for future work.

ben martin
08-01-2007, 10:43 AM
anyone made animations with Vue Xstream?
I'm not sure if I understood the question.
You mean, used Vue xStream 6 standalone to render animations or xStream/Lightwave integration animations?

Anyway I've use at booth situations.
In fact my team is actually producing a short-movie and all the landscape environments are Vue 6 xStream/Lightwave integration based.

The xStream 6 animation flicker issue (related to Vue 5 infinite) is much better now but some render parameters must be custom set to clean some vegetation flicker.

Using Vue 6 standalone to animate… well… the coordinate system and the pivot point setting to achieve complex models animation it is a complet headache.
Nicholas Phelps, (E-on president) once told me that they are not much worried with certain animation issues because Vue family are Landscape orientated software packs and not specific animation systems.
That's why they created xStream plug-in.
Using this xStream plug-in you can animate complex objects hierarchies inside the native program (e.g. Lightwave) and let to Vue the task to create the environment!

It makes sense… but I was a pain to the Vue dev team because I argued over and over that the users should be able to set up and animate complex object hierarchies (robots, space-ship with complex moving parts) inside Vue all alone.

Unfortunately, I couldn't make their minds about this!
Well, maybe to indulge me they included a new "local coordinate" system in Vue 6.
It is a add to the only "global coordinate" system present in previous editions (like Vue 5 Infinite) but this new "local coordinate" system did not solve the problems!

Hope this could help, somehow!

pixym
08-01-2007, 10:51 AM
damn-edit-time.
Anyway: i'd be curious about full GI rendering timing in Xtream, if E-on changes radically its licensing i could consider it.
By now, imho, a good solution to get instancing+GI+cache for animation is Kray. This scene has more than 1200 trees/shrubs and it render pretty fast, i'll give more percise infos because these were just first tests and i didnt keep track of times. Please dont look at poor design, its a preliminary phase and movie is needed just to describe urbanization. As said, i'm curious to know average time/frame with full GI in Vue for a similar scene.

Paolo

Paolo, can you tell me if AA has been fixed in kray and what is the render time for your example?

pixym
08-01-2007, 10:54 AM
Pavlov saw your post and made fast test here just now. Loaded old project into Vue and painted some trees and rendered. took about 5 min to setup scene and took 11min and 38 seconds to render. I set full GI to make comparable test with broadcast settings. also forgot 154 million polys

How can you have such a "fast" render time, I have played with the PLE version of Xtream Vue and my rendering was about 2 hours (dual woodcrest 3ghz) for a scene of mine???

pixym
08-01-2007, 10:56 AM
BTW: very interested thread.

Pavlov
08-01-2007, 11:12 AM
pixym, i'm doing attempts by now.
times are from 1 minute to 5 minutes on a 8 core 1.86 ghz, depending on technique used.
If i use Precomputed filtered mode, FG is not calculated and GI is just an interpolation of photons - very much like LW's GI in Montecarlo interpolated mode. This way i get extremely fast rendering (1 minute/frame) but i dont like GI very much. Using full photonmapping, with caching i'm around 3-5 min/frame depending on AA settings.
I guess on a AMD 4200 it would take something like 3 times more.

Paolo

pixym
08-01-2007, 11:58 AM
Thank you Paolo, and what build of kray version are you using?

vpii
08-01-2007, 11:59 AM
How can you have such a "fast" render time, I have played with the PLE version of Xtream Vue and my rendering was about 2 hours (dual woodcrest 3ghz) for a scene of mine???

Where you using spectral sky? I never use that it kicks up the rendering times by large amounts. So much of the rendering times is based off the sky/atmosphere you are using. Alot of times you can get the same look using standard atmosphere. Here is a link to a image I did for one of there gallerys. It took less then 3 hours to render using non GI for the landscaping.

http://www.cornucopia3d.com/galleries/displayimage.php?album=26&pos=225&pid=12328

Andyjaggy
08-01-2007, 12:03 PM
Does anyone know on the HD instance plugin if you get both the 32 bit and 64 bit versions? From their site it looks like you have to pick one or the other.

vpii
08-01-2007, 12:08 PM
Does anyone know on the HD instance plugin if you get both the 32 bit and 64 bit versions? From their site it looks like you have to pick one or the other.

That I know. I just asked last week. he said no because so much work went into the port to 64. Also there is issues right now in the 64 bit HD. They will be makeing new version for 64 soon.

pixym
08-01-2007, 12:15 PM
Where you using spectral sky? I never use that it kicks up the rendering times by large amounts. So much of the rendering times is based off the sky/atmosphere you are using. Alot of times you can get the same look using standard atmosphere. Here is a link to a image I did for one of there gallerys. It took less then 3 hours to render using non GI for the landscaping.

http://www.cornucopia3d.com/galleries/displayimage.php?album=26&pos=225&pid=12328

I will try without these settings... Thanks

pixym
08-01-2007, 12:17 PM
Does anyone know on the HD instance plugin if you get both the 32 bit and 64 bit versions? From their site it looks like you have to pick one or the other.
I have bought only the 32 bit version and I remember you have to buy the 64 bits version if you want to use it...

Pavlov
08-01-2007, 01:03 PM
pixym - Kray 1.7, beta 2.3.
Paolo

Andyjaggy
08-01-2007, 06:26 PM
That I know. I just asked last week. he said no because so much work went into the port to 64. Also there is issues right now in the 64 bit HD. They will be makeing new version for 64 soon.

That seems really silly to me. That would be like Newtek charging extra fro the 64 bit Lightwave. But hey it's their business and they can do what they want. I Would rather see a slightly higher price for both versions, then having to pay for both.

pixym
08-01-2007, 07:28 PM
This was done in 6 xstream. It is faster now…
You mean it is faster than Vue 5 or faster with the last build of Vue 6 xstream???
I know there is a recent update and it is what I am speacking about.

vpii
08-01-2007, 07:34 PM
it is faster then version 5.

pixym
08-01-2007, 08:06 PM
…I intensively tested this render times comparison (pure Vue scene stand alone render vs. xStream Lightwave integrated) and I can assure that if you are obtaining such bad results when integrating xStream and Lightwave you guys are doing something terrible wrong..
I am very happy to read this indeed, So I will push my investigation with the Xstream 6 PLE version...
Thanks Ben.

roger1972
08-02-2007, 01:40 AM
I'm not sure if I understood the question.
You mean, used Vue xStream 6 standalone to render animations or xStream/Lightwave integration animations?

Anyway I've use at booth situations.
In fact my team is actually producing a short-movie and all the landscape environments are Vue 6 xStream/Lightwave integration based.

The xStream 6 animation flicker issue (related to Vue 5 infinite) is much better now but some render parameters must be custom set to clean some vegetation flicker.

Using Vue 6 standalone to animate… well… the coordinate system and the pivot point setting to achieve complex models animation it is a complet headache.
Nicholas Phelps, (E-on president) once told me that they are not much worried with certain animation issues because Vue family are Landscape orientated software packs and not specific animation systems.
That's why they created xStream plug-in.
Using this xStream plug-in you can animate complex objects hierarchies inside the native program (e.g. Lightwave) and let to Vue the task to create the environment!

It makes sense… but I was a pain to the Vue dev team because I argued over and over that the users should be able to set up and animate complex object hierarchies (robots, space-ship with complex moving parts) inside Vue all alone.

Unfortunately, I couldn't make their minds about this!
Well, maybe to indulge me they included a new "local coordinate" system in Vue 6.
It is a add to the only "global coordinate" system present in previous editions (like Vue 5 Infinite) but this new "local coordinate" system did not solve the problems!

Hope this could help, somehow!

LW/MAYA/3DS/XSI and xstream integration... I'm just curious if someone have made an animation with Xstream Integration that works fine. If someone have made that I'm very happy if i could get a look at it...

ben martin
08-02-2007, 05:01 AM
LW/MAYA/3DS/XSI and xstream integration... I'm just curious if someone have made an animation with Xstream Integration that works fine. If someone have made that I'm very happy if i could get a look at it...

Sure, there are many examples, just see here some:
http://www.e-onsoftware.com/showcase/spotlights/

I specially recommend this one using Lightwave and Vue.
http://www.e-onsoftware.com/showcase/spotlights/?page=3

pixym
08-02-2007, 08:48 PM
I have followed your good advices Ben, and I get better results...
I keep on testing (or learning…) :thumbsup:

Andyjaggy
08-02-2007, 09:24 PM
I bought Vue a few months ago and have only played around with it a little bit but have been very pleasently surprised with how well it works.

I hear that it is very hard to get rid of the plant flickering in animations though. Does anyone have any experience with this? Also how well do the export buffers work?

ben martin
08-03-2007, 12:31 PM
I have followed your good advices Ben, and I get better results...
I keep on testing (or learning…) :thumbsup:
Cool! If you need help to clarify some doubts that you can’t figure out just feel free to ask! :)


I hear that it is very hard to get rid of the plant flickering in animations though. Does anyone have any experience with this? Also how well do the export buffers work?
Andy, I’ll get back to you with some answers and examples… just give me some time to finish something urgent over here.
Later I’ll post some examples and Vue render settings to avoid the flickering issue.

The export buffers had some small problems but they seems to work fine now. Be sure to get the last Vue 6 update 6-10-04 Build 291050.

I ‘m not sure if the Newtek forum administrator is going to find amusing and let us chat about Vue here… Lightwave Forum! :lwicon:
Anyway, I’m sure that many other worst things have been said and done without being pointed out! ;)

Let’s hope for the best!

pixym
08-03-2007, 12:34 PM
Cool! If you need help to clarify some doubts that you can’t figure out just feel free to ask! :) …/…
Thanks in advance Ben.

Andyjaggy
08-03-2007, 01:03 PM
Cool! If you need help to clarify some doubts that you can’t figure out just feel free to ask! :)


Andy, I’ll get back to you with some answers and examples… just give me some time to finish something urgent over here.
Later I’ll post some examples and Vue render settings to avoid the flickering issue.

The export buffers had some small problems but they seems to work fine now. Be sure to get the last Vue 6 update 6-10-04 Build 291050.

I ‘m not sure if the Newtek forum administrator is going to find amusing and let us chat about Vue here… Lightwave Forum! :lwicon:
Anyway, I’m sure that many other worst things have been said and done without being pointed out! ;)

Let’s hope for the best!

Cool thanks. Newtek doesn't care if we talk about other software, especially something that isn't direct competition for LW.

ben martin
08-07-2007, 09:03 AM
I hear that it is very hard to get rid of the plant flickering in animations though. Does anyone have any experience with this? Also how well do the export buffers work?
Like I promised, I'm back…uff.

So about flickering… yeap… Vue 5 Infinite has some issues with plants flicker but there are some tweaks to tune-up that particular issue.

Vue 6 render engine suffered important exchanges and the flicker issue is almost solved.
Nevertheless there are two points to consider when people plan a render a serious movie presentation.

The first one is:
Never render any scene using render presets lower than Broadcast.

The second:
Even, if the Broadcast preset is not enough to solve the problems the next steep is to select the RENDER settings to "User Settings" and tweak some parameters.
The most important are in the RENDER OPTIONS panel. (See the attached image)

The most important settings are Anti-aliasing though keep in mind that sometimes it won't be need to increase such parameters up to 10% of the already set values.
If you fall in the temptations to raise the sliders up to 100% you can very well wait till next Christmas to obtain a single frame render!

The process to find the best settings is almost a try and test render thing… but after you are happy you can use such setting to all the future works/scenes!

See the attached example movies.
If the flicker is good enough to your standards I can tell you that each frame took less than 5 minutes to render and yes, I tweak some anti-aliasing values.
Yeap I know, it’s a simple and almost non textured scene but it was done like that so you can identify the flicker easily.

Last but not the least:
Never render direct AVI compressed movies.
If possible always render uncompressed Hi-Q frames or Uncompressed AVI takes instead.
Later you can compress the final result to any codec after edit and post-production done.
The flicker will be much less noticed!
Less experienced people usually tend to edit using already compressed (to some degree) takes.
Compression increases the flicker problem very much and makes no sense to edit and do post-production to already compressed takes because all have to be re-compressed to the final movie codec.
I'll be a messy image quality!

There are other tips like over-scale the final render size to latter (in post production/edit) rescale down to fit the final codec export size resolution.
Example: Render the frames at 1024x(y) to latter resize down to final 720x(y) image movie.

Hope this help!

pixym
08-07-2007, 09:14 AM
What codec are you using?
The movie is blank here.

ben martin
08-07-2007, 09:18 AM
What codec are you using?
The movie is blank here.

It's an Mpeg movie... huh... If you can't find an free Mpeg codec I'll try other codec.. hold on!

ben martin
08-07-2007, 09:25 AM
Dhoo! :o
I can only post it latter…
I don't have here (I'm not at my studio right now) the uncompressed AVI files (best quality).
Latter I'll post two DivX avi files.
Using any other codecs will result in files larger than 5Mb… no good! :thumbsdow

pixym
08-07-2007, 09:47 AM
BTW: thank for the help.
No need to recodec it, I translate the file in my PC so then I saw it ;)

ben martin
08-07-2007, 02:03 PM
Here it is the second example! :)
This is a DivX file.

pixym
08-07-2007, 02:04 PM
Hello Ben,
Have you ever run Vue on XP 64 or Vista 64?

vpii
08-07-2007, 03:35 PM
Hello Ben,
Have you ever run Vue on XP 64 or Vista 64?

I run vue on xp 64 and it works very good

pixym
08-07-2007, 03:35 PM
OK, thanks vpii

vpii
08-07-2007, 03:49 PM
your welcome, you just have to download there 64 bit plugin. It has been very stable for me in 64 maybe even better then 32.

ben martin
08-07-2007, 04:13 PM
Hello Ben,
Have you ever run Vue on XP 64 or Vista 64?
Nop, I run away from Vista like from hell!
In fact if all the software I need had Linux versions... bye bye Windows!

fyffe
11-04-2007, 09:52 PM
Hi everybody. So, if I gather correctly, the major complaints about HD Instance are:

1) too slow
2) no FPrime
3) it's not a true across-the-board instancing solution

Is that correct? Let's see what I can do:

1) I keep speeding it up. I don't know if that 2-4 times slower figure even stands anymore... I wrote that sentence in 2004. There's some more speed enhancements coming soon.

2) I'd love to work with Worley to get that going.

3) Node support is mostly working (in beta). GI is already mostly supported, except for final gather, which I would gladly support if NewTek would open it up. What else is missing?

Greenlaw
11-04-2007, 11:13 PM
Hi everybody. So, if I gather correctly, the major complaints about HD Instance are:

1) too slow
2) no FPrime
3) it's not a true across-the-board instancing solution

Is that correct? Let's see what I can do:

1) I keep speeding it up. I don't know if that 2-4 times slower figure even stands anymore... I wrote that sentence in 2004. There's some more speed enhancements coming soon.

2) I'd love to work with Worley to get that going.

3) Node support is mostly working (in beta). GI is already mostly supported, except for final gather, which I would gladly support if NewTek would open it up. What else is missing?

Hi,

Just speaking for myself, but I haven't found HD Instance to be all that slow. In fact, over the years it's helped make my job much easier and frequently allows me to do what ordinarily would be impossible if not absolutely impractical with just native LightWave. Any speed improvements for HD Instance would certainly be welcome but that hasn't been a big issue for me.

FPrime compatibility, on the other hand, would be a big deal. If I had been able to render HD Instance in FPrime on a recent project, even if it was only a little faster, it would still have been very useful.

Also, being able to offset animation of instances. I know that wasn't possible when I asked for it a few years ago, but if it ever became possible, it would be fantastic. Right now, we work around this by instancing multiple versions of the same object, each with an offset animation. It's doable this way, but obviously it could be better.

One big feature I'd like to see, if it's even possible, is the ability to apply world coordinate displacement on the instances. For example, if I made a huge field of tall HD Instanced sunflower plants, this might let me apply a procedural texture to simulate wind blowing across the field. On a recent project I tried to get away with displacing the point carpet with hundreds of thousands of flowers, which sort of worked in my tests, but I wound up cheating a 2D effect in compositing instead. That worked fine because it was a wide shot but any closer and I would've had a problem.

By the way, keep up the great work!

DRG

Panikos
11-05-2007, 12:17 AM
Very happy to read all these :)

juanjgon
11-05-2007, 01:45 AM
Hi everybody. So, if I gather correctly, the major complaints about HD Instance are:

1) too slow
2) no FPrime
3) it's not a true across-the-board instancing solution

Is that correct? Let's see what I can do:

1) I keep speeding it up. I don't know if that 2-4 times slower figure even stands anymore... I wrote that sentence in 2004. There's some more speed enhancements coming soon.

2) I'd love to work with Worley to get that going.

3) Node support is mostly working (in beta). GI is already mostly supported, except for final gather, which I would gladly support if NewTek would open it up. What else is missing?

Hi Graham ... only one question ... how can we get this beta version? ... i really need the most solid version for 9.3 for a projects i am working now :)

trick
11-05-2007, 02:22 AM
Hi Graham ... only one question ... how can we get this beta version? ... i really need the most solid version for 9.3 for a projects i am working now :)

I'm still working in 7.5 for this very reason, so yes, I would like to know too !!

Pavlov
11-05-2007, 02:29 AM
Hi Graham,
i'm interested in HDinstance but, as i wrote privately time ago, i'd need at least it works with all LW's GI modes. Final Gather interpolated with GI caching across frames is the only really productive GI mode in LW for animation, HD should work with it. If working with Newtek could help you in bringing it to same LW speed, it would be another mayor thing, other instancing solutions (like Kray or other engines for other softwares) have 1:1 speed ratio.

But the one thing which would sell me immediately is Fprime compatibility.
I gave several tries in production to LW's GI, and even if it's very useable for exteriors, Fprime is still better both on quality and speed (better contact shadows and local refinement capability).
Few engines (if any) could compete with Fprime on exteriors, if it gets instancing.

eagerly waiting for good news,
Paolo

trick
11-05-2007, 03:01 AM
...other instancing solutions (like Kray or other engines for other softwares) have 1:1 speed ratio...

Keep in mind that most instancing is real geometry instancing where geometry is loaded on the fly/as needed, which is very forgving on memory when using a bucket renderer. HD is a volumetric instancing method, and I really like it since there is virtually no limit on the amount of polygons. I'm using VRay and finalRender with Max and believe me both have their limits. Once the polycount per bucket goes too high you have to resort to dynamic memory paging and then the 1:1 speed ratio is certainly not valid anymore !! The only downside with HD in LW is, that each base mesh has to be loaded in LW, which puts limits on the variety depending on the amount of RAM needed (loading 10 500k trees as bases for an instanced forest can put LW to a hold). On the other hand, random coloring of the instances is a lot easier then with VRay/fRender.

Captain Obvious
11-05-2007, 06:51 AM
Keep in mind that most instancing is real geometry instancing where geometry is loaded on the fly/as needed, which is very forgving on memory when using a bucket renderer. HD is a volumetric instancing method, and I really like it since there is virtually no limit on the amount of polygons. I'm using VRay and finalRender with Max and believe me both have their limits.
Kray does not have an upper polygon limit when using instancing, and neither does modo (I've rendered billions upon billions of polygons in modo, using instancing). They're only limited by the fact that each individual instance requires its own item, whereas HD-I instances onto the mesh. Imagine if you had to assign HD-I to a bunch of nulls! There's no way you'd be able to produce hundreds of thousands of nulls in a scene, but HD-I seems to quite happily render that.

Exception
11-05-2007, 08:41 AM
If working with Newtek could help you in bringing it to same LW speed, it would be another mayor thing, other instancing solutions (like Kray or other engines for other softwares) have 1:1 speed ratio.

Well.. HD Instance is really quite fast in most circumstances. In my other post, HD Instance with radiosity is certainly a lot faster than Kray with radiosity. I would say it's not easy to compare the two, and speed is certainly not one of HD Instance's issues.
Just my 2 cents.

Pavlov
11-05-2007, 08:51 AM
Tom, true but in the end you need to compare both with full AA... LW's AA is not that fast too.
If Kray does it in less than 3 min and HD takes 50 sec without AA, in the end times can be very similar (tif i got correctly your timings)... interesting thing would be trying to render 30 frames with cached GI on both systems, GI caching is quite different on LW and Kray.

Paolo

Exception
11-05-2007, 09:29 AM
Tom, true but in the end you need to compare both with full AA... LW's AA is not that fast too.
If Kray does it in less than 3 min and HD takes 50 sec without AA, in the end times can be very similar (tif i got correctly your timings)... interesting thing would be trying to render 30 frames with cached GI on both systems, GI caching is quite different on LW and Kray.

Paolo

No it was both with AA, hdI 50 seconds, Kray 2m30s with Grid 3 Mitchell non FSAA (photon estimate direct light trace).
I did do some animation tests, hence that other thread about flickering GI.
Anyway, both can both be optimized even more, and Kray is a fast render solution in most cases. Just to say, it's not so easy to compare and HD instance is certainly not slow.

archijam
11-05-2007, 11:11 AM
Kray does not have an upper polygon limit when using instancing, and neither does modo (I've rendered billions upon billions of polygons in modo, using instancing). They're only limited by the fact that each individual instance requires its own item, whereas HD-I instances onto the mesh. Imagine if you had to assign HD-I to a bunch of nulls! There's no way you'd be able to produce hundreds of thousands of nulls in a scene, but HD-I seems to quite happily render that.

This is superrr-true.

On one test with 9000 trees on a complex terrain:
I took the tree blocks in autocad, replaced all the symbols with a face (block edit), export to modeler, BG conformed to my terrain, added HD-I, hit render. No null bollocks whatever, all ranomness within HD. Sweet.

Well, actually I ran out of ram. But I was rendering 14 unique instances on my laptop ;) ...

j.

trick
11-05-2007, 11:29 AM
Kray does not have an upper polygon limit when using instancing...

Just render some 1000 1M poly trees within a very small part of your viewport/render (30x30 pixels). I tried this in Kray and Modo and it crashed...


This is superrr-true. On one test with 9000 trees on a complex terrain...

What happens if you take this scene and zoom out until it is completely contained in 30pixels of a 4000x4000 pixels render ?

cresshead
11-05-2007, 11:33 AM
i've just dipped into this thread at the end but i find the whole idea of 'having to look to 3rd parties for instancing'' just a bizarre state of affairs...

i started with 3dsmax 2.5 in 1999 and that had instancing and referencing 'in the box'...whilst it's really good to see someone outside of newtek making up for their lack of instancing in the core app it's VERY over due as a core item in lightwave 9 don't you think?

i think evey app apart form lightwave has instancing....about time to get out of the 90's and deliver true intacing and referencing in lightwave.

Andyjaggy
11-05-2007, 11:39 AM
It's a sad state of affairs.

archijam
11-05-2007, 12:30 PM
i've just dipped into this thread at the end but i find the whole idea of 'having to look to 3rd parties for instancing'' just a bizarre state of affairs...

i started with 3dsmax 2.5 in 1999 and that had instancing and referencing 'in the box'...whilst it's really good to see someone outside of newtek making up for their lack of instancing in the core app it's VERY over due as a core item in lightwave 9 don't you think?

i think evey app apart form lightwave has instancing....about time to get out of the 90's and deliver true intacing and referencing in lightwave.

AFAIK max cannot instance thousands of xfrog trees out of the box.

Vray can ... :)

j.

cresshead
11-05-2007, 12:32 PM
which max?

max9
or max 2008 64bit?

and which renderer?
scanline, radiosity, mental ray, brazil. final render?

vray is a plugin not a 3d app btw!


and lightwave can't instance 1 item....never mind 2 or 3 or a thousand...

archijam
11-05-2007, 12:45 PM
If you can get good rendertimes on 9000 instanced xfrog trees out of max, an ex-client of mine would like to hear from you...

I know what Vray is Cress, I was therefore referring to Vray for max, not another app (?).

In this case I was called in for the job since the other archi office couldn't handle the xfrog trees in the numbers required, and I could with HD-I. They tried everything (they were asking me what I did), tho I can't tell you which renderers they used, tho they ended up purchasing Vray.

I no longer use max or viz, so can't comment on the other render modes than scanline, mental ray, and radiosity.

j.

Exception
11-05-2007, 12:49 PM
i think evey app apart form lightwave has instancing....about time to get out of the 90's and deliver true intacing and referencing in lightwave.

What do you want more than a reiteration of the statement that it's on the books for the 9.x series?
It's being worked on. It's in the foreseeable future. Perhaps even weeks away.

Andyjaggy
11-05-2007, 01:01 PM
...perhaps even weeks away... Do you know something we don't :D

Exception
11-05-2007, 01:06 PM
...perhaps even weeks away... Do you know something we don't :D

Mostly just hoping... :)

Pavlov
11-05-2007, 01:47 PM
And the hope of many, in the highs of subtle planes, can *cause* this to happen, aint this true ? ;)

Paolo

archijam
11-05-2007, 01:51 PM
which max?
max9
or max 2008 64bit?
and which renderer?
scanline, radiosity, mental ray, brazil. final render?


Cress -
Do you know something I don't know? :) Please fill me in on the best way to generate extremely high detail instancing in max (specifically high poly xfrog trees .. pm if it's OT), i'd really love to know.

I agree by the way that LW should have instancing. Naturally in such a thread, we start to talk about the 'type' of instancing we want. I would the option to reference by layer, not just nulls. A la HD-Instance. A great plugin.

*From my point of view, right now for arch viz, where Vray is an extra $999 on top of your max/viz licence, well, it's too much for a small firm to pay if they get paid primarily for design, not for viz. That said, the links you posted to viz2008 were impressive, no question.*

j.

archijam
11-08-2007, 03:49 AM
Cress you never did give me an answer :( ..

One further point on LW and instancing.

Instancing is (or was not) not only about fast renders. Originally, the true need for instancing in 3D programs was that you need not place 500 copies of the same geometry in the same file, therefore bloating your overall file size, managability etc etc.

In LW, this has never been a problem due to the separate LWS and LWO filetypes, or rather, the 'problem' without instancing was shifted to the loading time of Layout :) ...

It is ill informed to suggest that all of the other programs were 'ahead' of LW, (3DStudio MAX 2.5 for example) just because they had instancing. They needed instancing for other entirely different reasons than what the current need is today (or has become) for Lightwave.

That said, LW is clearly missing a viable instancing inclusion, and it is now overdue.

j.

Jon_Bower
11-08-2007, 05:40 AM
I could really do with instancing : I got a forrest thats causing me probroblems. My wish is FPrime handles Instances.

fyffe
11-08-2007, 11:42 AM
What happens if you take this scene and zoom out until it is completely contained in 30pixels of a 4000x4000 pixels render ?

With HD Instance? It will render really, really fast.

fyffe
11-08-2007, 11:43 AM
Hi Graham ... only one question ... how can we get this beta version? ... i really need the most solid version for 9.3 for a projects i am working now :)

Anyone who has bought HD Instance already can just shoot me an email and I'll send it over. Only the win32 beta is built at the moment.

fyffe
11-08-2007, 11:44 AM
Also, being able to offset animation of instances. I know that wasn't possible when I asked for it a few years ago, but if it ever became possible, it would be fantastic.

This feature is already in HD Instance 2.0, which I expect will be released soon.

dmack
11-08-2007, 12:16 PM
OOOOH First you've mentioned of version 2! Great to hear it's out soon! Really looking forward to that!

Can I go back in time now and re do some projects?

pixym
11-08-2007, 12:18 PM
Can you tell us more about the V2?

Exception
11-08-2007, 12:37 PM
With HD Instance? It will render really, really fast.

Have you checked your email?
There's a slight issue with this... I sent you the scene and objects and everything...

dmack
11-08-2007, 12:38 PM
This feature is already in HD Instance 2.0, which I expect will be released soon.


I've often wondered - can you do this whilst not using the amount of memory that you would wit regular geometry? Don't really understand how it all works...

Second pixym, any other features you can tell us about in Version2?

Sensei
11-08-2007, 12:55 PM
Don't really understand how it all works...


In reflective surface you don't have geometry too, but is somewhere else in the scene - it's just redirection of ray position and direction..

juanjgon
11-08-2007, 01:03 PM
I've often wondered - can you do this whilst not using the amount of memory that you would wit regular geometry? Don't really understand how it all works...

Second pixym, any other features you can tell us about in Version2?

It is really simple ... in a few words you must transform the ray using transformation matrix of each instance, check intersection with original geometry and then trasform all intersection data (point, normal ...) with the inverse of this instance transformation matrix. With this data you can now compute illumination and shading data ... of course coding it is a bit complex like this ;)

dmack
11-08-2007, 03:40 PM
It is really simple ... in a few words you must transform the ray using transformation matrix of each instance, check intersection with original geometry and then trasform all intersection data (point, normal ...) with the inverse of this instance transformation matrix. With this data you can now compute illumination and shading data ... of course coding it is a bit complex like this ;)

Wow, I dread to think what would follow a "It's really complex...." from you!

:)

So in short, it wouldn't take a load more memory to do offset animation, just some extra coding from Graham?

Sensei
11-08-2007, 03:54 PM
So in short, it wouldn't take a load more memory to do offset animation, just some extra coding from Graham?

If I understand correctly offsetting animation as different instance time than instance source, the answer is - it's impossible.. Or nearly impossible.. LWSDK returns object in current state at current time and frame and there is no way to tell at which time you want object.. Plug-in would have to back-up all data in memory when they are rendering frame xxx, and then lookup that database instead of current frame.. So, it would not work in renderfarm where frames are not rendered in progressive order one by one.. And it would not also work with offsetting to future look of instance source (because database has what was rendered, and does not have what is not yet rendered).

mav3rick
11-08-2007, 04:03 PM
how about bake data into file for renderfarm?

trick
11-08-2007, 04:04 PM
With HD Instance? It will render really, really fast.

Yes, I know. But with Kray, VRay, Mental Ray, fRender or any geometric (dynamic memory) method this may not render at all with a certain amount of memory. With volumetric instancing you can render zillions of instances in one pixel under the condition that the base meshes render in that same amount of memory.

If 2.0 is that near, why still bring out 1.8 ?

archijam
11-08-2007, 04:10 PM
If I understand correctly offsetting animation as different instance time than instance source, the answer is - it's impossible.. Or nearly impossible..

From my experience with HD Instance ... it is possible, but it's a cheat :) (((if I understand the original question correctly)))

(Not saying you are wrong Sensei, just that there may be a work around ...)

For example, you can mix several (let's say 5) objects into one HD Instance 'instance'. Each of these could have different animation timings (given v2). This will not compute as fast as 1 object instanced, but most likely faster than 5 seperate instances (which would also be harder to set up).

If you noticed the repetition, you can also change the 'seed' value to get a different, less obvious result ...

j.

fyffe
11-08-2007, 04:34 PM
If I understand correctly offsetting animation as different instance time than instance source, the answer is - it's impossible.. Or nearly impossible..
HD Instance 2 will use a baked motion file to achieve it. Works fine :D

Sensei
11-08-2007, 04:43 PM
Yeah. Baking mesh to file at every frame is off-line method of filling database. That's pity 3rd party programmers have to use such workarounds to bypass LW limitations..

dmack
11-09-2007, 01:43 AM
HD Instance 2 will use a baked motion file to achieve it. Works fine :D

Cool! Is it easy to set up and does it work with network rendering?

Can you do recursive* instancing in Version 2 (or is that something you could add at some stage?). *Instance something that already has instances on it?

Some other thoughts I had for a future version of HD Instance....

1. Alternative placement options - stated (eg 300/meter squared) density, (additionally modulated by vmaps) rather than relying on points or polies on the mesh
2. Crude collision detection, so bounding boxes don't overlap?
3. Any chance of getting instances to work with glow?
4. Any chance of getting HD instance to talk with ParticleFX so that the particle group can dictate what item is instanced? It would be really cool for example to be able to have every particle instance a ball, then, if that particle hits something (triggering a group change), it changes to an animation of a ball shattering (starting from a whole ball to hide the switch over and then breaking apart). That is one simple example to demo what I mean but the possibilities would be endless! You could do some seriously cool effects with that!!!!!

trick
11-09-2007, 02:17 AM
HD Instance 2 will use a baked motion file to achieve it. Works fine :D

Will this motion file be read on the fly or does it read into memory completely. This would make a substantial difference for me. I once bought PointOven for that reason. I have MDD's that are over 20 Megs in size, so loading some of them into memory with large scenes can give trouble. Especially with 100K poly characters on the fly MDD reading has its advantages.

Pavlov
11-09-2007, 05:14 AM
Graham, correct me if i'm wrong but long time ago comeone here did a beautiful anim of a hundred Mech walking using HDI, i seem to remember he used MDD baked motion for that.
Is this true, and if yes why baked motion shouldnt work on current versions ?

Paolo

dmack
11-09-2007, 05:33 AM
Did whoever did that have say three or five differently timed anims and then randomly instance them? I used this technique a while back to offset multiple instances.

I'm hoping that version 2 will simply allow you to say how far in advance or arrears the instances play (inc randomization) and all the baking etc is done in the background, without much user intervention (except where the baked file goes!)

fyffe
11-09-2007, 03:37 PM
Graham, correct me if i'm wrong but long time ago comeone here did a beautiful anim of a hundred Mech walking using HDI, i seem to remember he used MDD baked motion for that.
Is this true, and if yes why baked motion shouldnt work on current versions ?

Paolo

I did a mech anim, and someone else did too, but no baking was required. All the mechs are walking in synch. The new feature will allow instances to be out of synch with each other.

Qexit
11-09-2007, 03:48 PM
If 2.0 is that near, why still bring out 1.8 ?Presumably, not everyone will want to upgrade to 2.0 and, although I'm sure the cost will be very reasonable, not everyone will be able to afford to upgrade to 2.0. So Graham will release 1.8 to allow users who fall into one or other of these camps to use HD_Instance in LW 9.3 without several of the current bugs/problems. Graham is like that. He cares about his users/customers :thumbsup:

nthused
11-10-2007, 08:15 AM
He cares about his users/customers :thumbsup: :thumbsup: Indeed. He and a few others in the LW Plugin development community are the reason LW is still a viable program for me. You da man, Graham.

fyffe
11-23-2007, 10:52 PM
Will this motion file be read on the fly or does it read into memory completely. This would make a substantial difference for me. I once bought PointOven for that reason. I have MDD's that are over 20 Megs in size, so loading some of them into memory with large scenes can give trouble. Especially with 100K poly characters on the fly MDD reading has its advantages.

Oh, don't worry about THAT :D

Pavlov
11-24-2007, 03:30 AM
Trick, i also had issues with large MDDs for characters... for sure you already know, but i solved this re-baking motions each Nth frame (from 3 to 5, depending on motions). now most MDDs are averagely 3 Mb and there's really no noticeable difference in motion.

Paolo

pixym
11-24-2007, 05:21 AM
Trick, i also had issues with large MDDs for characters... for sure you already know, but i solved this re-baking motions each Nth frame (from 3 to 5, depending on motions). now most MDDs are averagely 3 Mb and there's really no noticeable difference in motion.

Paolo
Hey, that is a nice tip! thx Paolo.

trick
11-24-2007, 05:54 AM
Trick, i also had issues with large MDDs for characters... for sure you already know, but i solved this re-baking motions each Nth frame (from 3 to 5, depending on motions). now most MDDs are averagely 3 Mb and there's really no noticeable difference in motion.

Paolo

This works for my low and mid poly models, but not for the high res stuff. These are models that are in the foreground at a certain point in time and then even missing one frame can have odd results. This could be solved by putting keyframes at certain intervals during motion setup, but this is not an option since then I need to redo a lot of them.

trick
11-24-2007, 06:03 AM
Oh, don't worry about THAT :D

:thumbsup:

In the next release, will there be an option to scatter instances on surfaces/objects just by defining a density and/or a random parameter (or something like that) for that surface/object, instead of spraying points ?

Pavlov
11-24-2007, 06:42 AM
Trick, sure not ideal for hi-rez character stuff... i was talking moslty from an arch-viz pov, where characters are not protagonists. If you're into charanim work, it's a whole different question.

Paolo

jin choung
11-24-2007, 03:07 PM
yah, problem with the every nth frame is the whole nyquist thingie....

at any given nth frequency, you could be missing peaks and valleys positions of your animations... and unfortunately, even if you could make an mdd recorder that lets you specify nth frame but still manually specify important peak/valley keys, you'd have to do that for not just a character but all his parts - whose peaks and valleys would not coincide with each other.

yah, not for main chars.

jin

fyffe
11-25-2007, 02:09 PM
In the next release, will there be an option to scatter instances on surfaces/objects just by defining a density and/or a random parameter (or something like that) for that surface/object, instead of spraying points ?

There sure will! You can have a whole landscape and just set it to 100x100 grass blades per meter, or whatever. So trillions of instances are now possible. With weight maps too :)

archijam
11-25-2007, 02:15 PM
Graham - Great to see you back here .. you have been busy since siggraph :) ...

Please check your pm.

j.

Exception
11-25-2007, 02:18 PM
There sure will! You can have a whole landscape and just set it to 100x100 grass blades per meter, or whatever. So trillions of instances are now possible. With weight maps too :)

Good god, I soiled the carpet!

juanjgon
11-25-2007, 02:27 PM
There sure will! You can have a whole landscape and just set it to 100x100 grass blades per meter, or whatever. So trillions of instances are now possible. With weight maps too :)

My dream comes true :) ... cant wait ... eeeerrr, do you need a beta tester? :) :) :)

pixym
11-25-2007, 02:54 PM
These things are really nice to read!

cresshead
11-25-2007, 03:02 PM
be even better to read when the next beta of lw9.* finally HAS instancing of any kind.

:D :thumbsup: :lwicon:

bjornkn
11-25-2007, 03:05 PM
The future definitely sounds very interesting.
I have spent a lot of time experimenting with v1.8.1 and GrassGenerator and got very promising results, like the one attached. There are only around 2-3 milion grasses though, each with between 12 and 48 polys, but then the test area isn't bigger... ;) Renders quite fast even with GI and DOF.

archijam
11-25-2007, 03:25 PM
be even better to read when the next beta of lw9.* finally HAS instancing of any kind.

:D :thumbsup: :lwicon:

Cress you never answered my questions (http://www.newtek.com/forums/showthread.php?p=615463&#post615463) about (render) instancing and MAX ..


j.

cresshead
11-25-2007, 03:46 PM
hi

like i said it all depends on 'what' your rendering in which version of max, on what o/s and with 'what' renderer....

lots of variables in there!
i don't use xfrog so a xfrog specific reply to a scene is going to be difficult but 3dsmax is quite capable out of the box in regards instancing...

you can read about mental ray specific's over on the area where it's a better place to post Q's on max than here really or also cgtalk...

final render can render 'billions' of instances and has done for many years...even the stage -o- [$90] version that was back in max 4 days btw!

i think 3dsmax is quite capable 'as is' using mental ray and max2008 on a 64bit system...if you don't try the brute force approach you can do even more faster...ie put your compositor to good use.

archijam
11-25-2007, 04:22 PM
Not trying to 'call your bluff' Cress, I'm genuinely interested (and so would my MAX using colleagues). For me it will always be a super-high poly (tree) affair, and HD I does the job well that alot of other 3D apps can't (at least out of the box and to my (our) knowledge).

Cheers!

j.

cresshead
11-25-2007, 04:45 PM
for hi poly trees i'd use vue as it was free with my lightwave upgrade and can link to ALL 3d apps or can composite without too much hassle.

re x frog...no idea don't use it...sorry!8~

re max out of the box..well not really had much hassle in scenes and that'll only get better when my 8gig ram quadcore comes back and i can move from my Acer laptop [1gig ram] to the quad core for production!:thumbsup:

Q. do xfrog trees have built in level of detail modifiers or do they rely on brute force poly instancing of hi res models regardless of how close to the camera they are in the scene?

Exception
11-25-2007, 05:01 PM
Xfrog trees are just objects. They're not plugins. You can generate various quality levels per object if you desire, but that's a manual task.

They are, however, the most detailed and precise trees I've seen from any generative program. Vue doesn't hold a candle to Xfrog trees, not in terms of quality and not in terms of variety of species.

trick
11-25-2007, 05:17 PM
There sure will! You can have a whole landscape and just set it to 100x100 grass blades per meter, or whatever. So trillions of instances are now possible. With weight maps too :)

Surely interesting. Hedges, flowerbeds, etc.come to my mind. Next to the already present random coloring can individual instance coloring be influenced by these weightmaps (even a pure black/white influence would be awesome !!) ?

Chad_Shadow
12-13-2007, 10:47 AM
Quote:
Originally Posted by fyffe
There sure will! You can have a whole landscape and just set it to 100x100 grass blades per meter, or whatever. So trillions of instances are now possible. With weight maps too


fyffe ... That would be AWSOME ... You're making our dreams come true !! ... GOD BLESS YOU !! :)

Chad_Shadow
12-13-2007, 11:28 AM
Nice Thread by the way ...

I have an urban project (1Million sq meter) full of landscaping elements (water, trees, shrubs,etc ...) with a lot of bridges / urban objects (lights, seats, etc ...)...

Thanks to each of you i've been introduced to different software as Vue, Kray, Modo, XFrog, Plant Studio.

Still planning how to start and what to optimize to reach a level similar to the link posted earlier: http://tirad.com/gallery/02_007h.htm

The main tools we agreed upon are: HDInstance (with XFrog trees) and we will drop for now FPrime (HDInstance more important) and use Newtek Native Rendering (hoping 9.0 Radiosity rendering can serve the task "time-wise") ...

Cheers

pixym
12-13-2007, 11:31 AM
Nice Thread by the way ...

I have an urban project (1Million sq meter) full of landscaping elements (water, trees, shrubs,etc ...) with a lot of bridges / urban objects (lights, seats, etc ...)...

Thanks to each of you i've been introduced to different software as Vue, Kray, Modo, XFrog, Plant Studio.

Still planning how to start and what to optimize to reach a level similar to the link posted earlier: http://tirad.com/gallery/02_007h.htm

The main tools we agreed upon are: HDInstance (with XFrog trees) and we will drop for now FPrime (HDInstance more important) and use Newtek Native Rendering (hoping 9.0 Radiosity rendering can serve the task "time-wise") ...

Cheers


Héhe, Talking about Trees/Plants density, you are not the only one who want to reach the Renderfram.ru guys ;)