PDA

View Full Version : Core: Instances



lordtangent
02-14-2009, 02:38 PM
I was thinking about instances a little today and it occurred to me how great they are going to be for even pedestrian stuff like shadow casting objects. It might even be possible to do some crazy stuff like applying different light linking/surfaces to instances yet compositing them right in the renderer without suffering a huge hit in render time or memory usage. It could allow for breaking up lighting rigs in some pretty interesting ways.

Captain Obvious
02-14-2009, 02:51 PM
Instances have about as big a hit on rendering speeds as non-instanced objects do. Basically, it's just about saving memory.

lwanmtr
02-14-2009, 03:08 PM
I hope that there will be a plug or something so that we could generate mass foliage and such with random placement and rotations..and following the ground :)

Silkrooster
02-14-2009, 07:32 PM
I hope that there will be a plug or something so that we could generate mass foliage and such with random placement and rotations..and following the ground :)

I was thinking of that last night. Having a way to distribute the instances would be more important now than it use to be with the point clone tool.
Better array tools, preferably with an option of hugging the selected geometry would be very useful. With the manipulators the tool should be updated in real time.
But I guess we will have to wait and see if it is included and if not what plug in will fill that void.

wacom
02-14-2009, 07:38 PM
If CORE really is nodal there will be no need to wait for a plugin.

If the whole node thing pans out, there is no reason you shouldn't at least be able to make an object an emitter of your instanced geometry and then paint (on the branches in this instance) a weight or texture map input for where you want the leaves to be "emitted" from.

In addition, you should also be able to somehow paint yet another map for control of the main vector directions etc.

Things like an animated map or map intensity would allow you to control size etc. for things like growth of the instances size and more.

In addition you should be able to create either a simple equation node or another map that states the start of the emission is something like x (for the start of where it is on the geometry) + y so that you could make the leaves that much of a distance away from their original position and thus make the tree look more full of leaves without adding a million branches. It would be ideas if they give us a randomize by range value node for such a purpose to add some variety. These ranges could, also be controlled by a weight or image map...

robk
02-14-2009, 07:49 PM
I hope that there will be a plug or something so that we could generate mass foliage and such with random placement and rotations..and following the ground

In 9.6 it is called HD Instance

lwanmtr
02-14-2009, 10:09 PM
'cept HDInstance is rather limited in alot of ways..for instance, it wont instance any light rigs attached to an object..and HD Instance requires a point cloud to work you cant drive it with a texture or anything.

dwburman
02-14-2009, 10:41 PM
Actually, you don't need a point cloud for HD_Instance. You can choose to use points or polys and (I think) the latest release allows the use of weightmaps to control density.

HD-Instance manual (http://happy-digital.com/hdinstance_documentation.pdf)

lwanmtr
02-14-2009, 10:46 PM
Points or polys...still means it requires a mesh (basically) to know where to generate..you cant just open a panel, type in # of copies, some other info (randome rot, etc...). You can use deformations and such, which is nice. But I'm hoping that we will be able to automatically generate instances...the nodal design of Core looks promising to deliver that :)

dwburman
02-14-2009, 10:57 PM
Yup. I'm looking forward to the open architecture of Core.

Cageman
02-15-2009, 05:19 PM
Points or polys...still means it requires a mesh (basically) to know where to generate..

Actually, using mesh or points as a base for generating instances is really, really usefull (I mean... if you want thousands of instances for an army, using a mesh to place them exactly where they should be is timesaving to say the least). Oh..and I do believe that you can place instances at Nulls as well, so no NEED for mesh, really. Just create a bunch of nulls and place them where you want and instance to them.

I'm not sure, but I believe that in Maya you are limited to use instances with particles (however, particles can easily be generated from any type of mesh), but alas, it requires some additional steps. HD Instance seems to be alot faster to work with compared to Mayas instancing.

With that said, Mr.Rid had some very interresting things to say regarding the limitations in LW when it comes to make instances (or any type of object) to follow a terrain and in more detail control the allignement of the instances when they, for example, move over a hill. So, that is where I hope CORE will end up having tons of control in the future (if not by NT, maybe by some third party Python hacker). :)

lordtangent
02-15-2009, 06:43 PM
Instances have about as big a hit on rendering speeds as non-instanced objects do. Basically, it's just about saving memory.

I don't think you understand what I'm getting at. I'm talking about "shadow casting only" objects and other similar uses where the instance isn't necessarily visible to the camera. Of course there would be a slight render hit. But, for example, if the visible object DIDN'T cast a shadow and the invisible to camera instance DID, the render time should be about the same since the amount of rays being cast is about the same. Only now with instances there is no memory hit either.

In high end work is is very common to break out lights like crazy. So any tool that helps produce the combination of light linking you want without increasing memory usage is good.

Actually, come to think of it, that is one area I hope they improve also. The light exclusion lists in old version of LW were always brittle and difficult to roll out in a "rig". It would be nice if there was a good default way of handling that. Though, I guess now with Python you could always make a script to do it.

akademus
02-16-2009, 02:14 AM
So far I found HD instance to be just irreplaceable when you have enormous amounts of repetitive stuff in the scene.

Captain Obvious
02-16-2009, 01:21 PM
I don't think you understand what I'm getting at. I'm talking about "shadow casting only" objects and other similar uses where the instance isn't necessarily visible to the camera. Of course there would be a slight render hit. But, for example, if the visible object DIDN'T cast a shadow and the invisible to camera instance DID, the render time should be about the same since the amount of rays being cast is about the same. Only now with instances there is no memory hit either.
Ah, right. Yeah, instances are very useful in cases like that.

wacom
02-16-2009, 01:44 PM
Well, all I know is from what I've seen in Houdini and actually used in XSI- and from that I can say that nodes are going to allow a lot of us to do quite a bit of things on this front that simply are not possible even with HDinstance.

To be sure, HD instance has many advanced features that go beyond basic instancing (not so much in the placement front as in their animation and texturing options etc.). However, if this can, and probably will, have some nodal form or presence, then it's going to an amazing thing to work with.

Mike_RB
02-16-2009, 01:47 PM
Well, all I know is from what I've seen in Houdini and actually used in XSI- and from that I can say that nodes are going to allow a lot of us to do quite a bit of things on this front that simply are not possible even with HDinstance.

To be sure, HD instance has many advanced features that go beyond basic instancing (not so much in the placement front as in their animation and texturing options etc.). However, if this can, and probably will, have some nodal form or presence, then it's going to an amazing thing to work with.

I don't think it's sunk in yet that if they do 'stack and history and nodes' right you get a procedural system akin to houdini. Where you have an entire app that works like 'ICE" in XSI. Very cool. I hope Newtek pulls it off.

Cageman
02-16-2009, 02:11 PM
I don't think it's sunk in yet that if they do 'stack and history and nodes' right you get a procedural system akin to houdini. Where you have an entire app that works like 'ICE" in XSI. Very cool. I hope Newtek pulls it off.

Amen! And, since Jonas favours Houdini above any other app, I'm sure they hold it as an inspiration.

:)

lordtangent
02-16-2009, 06:53 PM
Amen! And, since Jonas favours Houdini above any other app, I'm sure they hold it as an inspiration.

:)

Wow, I didn't know that. What excellent news. IMHO, you could not go wrong with a system inspired by Houdini, yet incarnated though the lens of a LW user.

lwanmtr
02-16-2009, 08:04 PM
Yeah..I tried a tutorial in Houdini and it's pretty powerful..but having that kind of power with the user friendliness of LW wold be awesome.

mosconariz
02-16-2009, 11:10 PM
Yeah..I tried a tutorial in Houdini and it's pretty powerful..but having that kind of power with the user friendliness of LW wold be awesome.

The power of Houdini but the friendliness of Lightwave?

Wow, they should have named this aplication as: Penn & Teller :dance:

Captain Obvious
02-17-2009, 06:17 AM
Yeah..I tried a tutorial in Houdini and it's pretty powerful..but having that kind of power with the user friendliness of LW wold be awesome.
Uhm? To be perfectly honest, I find Houdini exceptionally easy to use. The UI is very straight-forward with clear labels, and it has one big advantage over LW in that regard: consistency. Framing your selection is the same button in all viewports, quite unlike LW where it seems to vary from viewport to viewport...

Lightwave's strength is not its user interface. Once you know how to use it, Lightwave can have a very easy-to-use workflow, but this is not thanks to the UI. Instead, it's because of the directness of how most things work. You never really need to plan ahead. A box is just six polygons, it's not a "box primitive" that you have to make editable and convert into polygons or whatever, la Max. In Houdini, because of how the procedural system works, planning ahead is everything. Having "the power of Houdini" within LW's UI, well, it doesn't really make sense.

Nemoid
02-17-2009, 11:10 AM
i tend to agree.
Houdni workflow is surely more complex, because it is endlessly flexible, So starting out simple things can be longer, but at the end of the day if the work you have to do is highly stratified and complex, you can manage it quite easily.

lordtangent
02-17-2009, 11:32 AM
There is no reason why nodes and procedurallism could not be applied to LWs "directness". In fact, that is the direction I would encourage NT to push things. "Nodes that make sense" because of their obvious application and directness.

Nicolas Jordan
02-17-2009, 01:56 PM
I doubt the instancing in Core will be anything more than what programs like modo or Blender can do, at least in the first version anyway.

Captain Obvious
02-18-2009, 09:08 AM
There is no reason why nodes and procedurallism could not be applied to LWs "directness". In fact, that is the direction I would encourage NT to push things. "Nodes that make sense" because of their obvious application and directness.
Yeah, but you'd still lose the "I want to move this vertex" directness of Modeler, if you have to consider *where* in the node flow you want to move it.

Mike_RB
02-18-2009, 10:04 AM
Yeah, but you'd still lose the "I want to move this vertex" directness of Modeler, if you have to consider *where* in the node flow you want to move it.

Not if you just keep daisy chaining things together with automatic history locking. (So the recipe is still there, just locked away and not being cooked). For the people not interested in branching live procedural node trees, they can just get along with their vertex massaging. Adding thousands of transform nodes with single vert moves.

Captain Obvious
02-19-2009, 04:24 AM
Not if you just keep daisy chaining things together with automatic history locking. (So the recipe is still there, just locked away and not being cooked). For the people not interested in branching live procedural node trees, they can just get along with their vertex massaging. Adding thousands of transform nodes with single vert moves.
Yeah, that would work I guess, but then you have a split between actually actively using the procedurality and not using it. If you want to use it, you still lose the directness of current Lightwave. Even if the software lets you choose between eating your cake and keeping it for future consumption, you still can't have both at the same time.

Mike_RB
02-19-2009, 06:22 AM
Yeah, that would work I guess, but then you have a split between actually actively using the procedurality and not using it. If you want to use it, you still lose the directness of current Lightwave. Even if the software lets you choose between eating your cake and keeping it for future consumption, you still can't have both at the same time.

How much locking would have to be done is to be determined by how slow it would be to keep the recipe live. We might be able to have our cake and eat it too.

Captain Obvious
02-19-2009, 01:27 PM
How much locking would have to be done is to be determined by how slow it would be to keep the recipe live. We might be able to have our cake and eat it too.
If you just mash your model together as you do now, you wouldn't really be able to use the history anyway, even if it was there. To take advantage of the procedural workflow, you need to actually build your assets in a way that makes that possible. A "mashed-together" asset can't really be "proceduralized" after it's been finished.

Mike_RB
02-19-2009, 01:35 PM
If you just mash your model together as you do now, you wouldn't really be able to use the history anyway, even if it was there. To take advantage of the procedural workflow, you need to actually build your assets in a way that makes that possible. A "mashed-together" asset can't really be "proceduralized" after it's been finished.

I'd still prefer having that garbage history. People will just ignore it or freeze it. But for the rest of us that want to exploit it, it will be there.

Captain Obvious
02-19-2009, 02:12 PM
Yeah, that's fair enough and I probably agree. But surely you agree that you still can't get a procedural asset while still using the same direct manipulation method as you're doing now.

Mike_RB
02-19-2009, 02:55 PM
Yeah, that's fair enough and I probably agree. But surely you agree that you still can't get a procedural asset while still using the same direct manipulation method as you're doing now.

Of course. But that's my #1 wish for core, to be a modern LW rewrite with houdini running just under the surface if I go digging.

Netvudu
02-19-2009, 03:50 PM
I wish, but I sincerely doubt that will be the case.
Im sure Lightwave will have a great history, and maybe even a nice node system, but Im not sure it is possible to keep proceduralism and destructive-like workflow at the same time. I just dont see how.

If Core goes for optional node systems running under the hood, Im going to bet it wont be a Houdini-like structure, but more something like ICE or Maya hypergraph which are not true procedural at their hearts, but more like linear structures with node interfaces.

Anyway, being myself also a happy Houdini user (besides a happy Lw user), its a win-win situation for me, right? :)

Regarding instancing, I must say that I worked some instancing in Houdini for a few scenes, and let me tell you that even being native, you will be far from the ease of use of a wonderful tool such as HD Instance. I think many users give it for granted, and dont realize what we got there is the closest thing to a studio propietary tool, which allows us to do things that usually take A LOT of work IN ANY PACKAGE.
It took me 5 days of work in Houdini to get a scene with properly offsetted animation for all the instances, including particle animation and everything. Admittedly, I was learning many things in the process, and everything would be quite reusable now for another scene, and also I can change some stuff that HD Instance wouldnt allow, but the fact is I replicated the same scene with HD Instance from scratch in about 2 hours (and it looked even slightly better). Hows that for speed?

Im doing stuff with Houdini daily (also with LW), and some of that stuff no other package can do (not just the current LW but also Maya or XSI), but trust me, instancing the way HD Instance does it, even having some shortcomings, is far from easy no matter the package.

my 2 euro cents...