PDA

View Full Version : CORE object instancing.



serge
12-10-2009, 12:15 PM
I have some questions about object instancing in CORE. I hope these can already be answered.


I'll take a tree as an example. I create a leaf and instance it several times to place them along a small branch. Now I want to instance that branch together with the leaf-instances several times and place them along a bigger branch. Questions:

1) After I instance the branch with leaves, are the leaves also still considered an instanced group?

2) Can I modify (i.e. bend) one instance (and will it stay part of the group)?

3a) Can I select some of the instances and make this selection a new instance-group?
3b) And can I later combine these two groups again?

4) Can I replace the instances with an other object (and respect the rotation data of course)?

5) Can instances have different weightmaps?

6) Can instances have different textures?

7) Can I animate instances separately? And will they work as seperate objects or 'parts' in dynamics?

8) For the upcoming Lightwave HC version, can instances be moved back and forth between CORE and Layout/Modeler?

Drakaran
12-10-2009, 03:01 PM
I'm betting it'll be along the lines of instancing in Houdini. In it, each node can be animated/edited/etc as well as groups of nodes, etc.

I really like Houdini other than it's a MONSTER to set stuff up in. I'm hoping LW will have it's flexibility, but have some basic stuff preconfigured as defaults so there isn't so much set up.

Tobian
12-11-2009, 09:53 AM
Good questions.. that you are unlikely to get an answer too soon haha :)

However, the simplest answers are: What can you do with 'instances' in LW at present, since all objects in a scene can be 'instanced'. It's not the same exactly, but the logic is still sound. Likewise HDinstance is also a good guide to what's likely possible.

Since all an instance is is a set of coordinates and an ID number, you can do anything you can normally do with that idea.. group it, rotate it, position it, scale it, animate it etc. You can apply attributes based on it's position, or have nodes which randomly vary colour (You can do this at present in 9.6, with DP's item info nodes). Likewise using nodal inputs it's highly likely you can nodally control an object's physical properties, on a per-item basis, such as controlling how many segments it has or how far along a path it's grown (for growing creeper vines etc), because modeling functions are tied in with nodes in Core.

It's likewise unlikely you can apply different geometry data to instances, as really that pushes the concept. but you could contain within an instance things like a morph, which you could control using other nodal inputs on a per-instance basis. It's probably more practical to just have a few base models (a few different leaf models or grass blade models) to help vary the repetition, rather than try and make one do-everything single model :)

As for deformations, that's hard to say, but it's possible, as you can have displacement mapping as a per-object-instance thing in LW now. So I think the answer is mostly: Whatever you can do to an 'instance' of an object in LW layout now, you can likely do in Core (assuming it has those tools yet!). The real question is likely what sort of 'poupulation' tools it will have... Tools to help you place a random grass model, from a choice of 10 variations, or leaves, or feathers, and then position and groom them etc. Which then makes me think, with good placement tools and instances, you almost don't need hair tools :D

serge
12-11-2009, 02:16 PM
Thanks for the reply Tobian.

Yes, positioning tools are very important as well.

Flexible instancing and a complete and integrated dynamics engine, might be enough reason for me to buy CORE. But I'd like to know all the details, what it can and can't do (preferably before the price changes from $500 to $700).

Tobian
12-11-2009, 02:40 PM
Alas I couldn't tell you if I knew :P It is implied the dynamics engine is integrated, and fully interoperable with the node architecture of core (because apparently everything is, by design) Exactly what that means, and what is actually.... working.... yet, or by the time of release, is likely not going to be expanded on until the price goes up I am afraid! :)

Sensei
12-11-2009, 02:59 PM
If instance is animated or edited other way than changing position, rotation or scale of whole instance, then it's no longer real instance, because it must eat memory.. Such instances have sense only in bucket renderer, which is generating geometry on demand while ray is traveling through region. Then it's keep in memory, until reaching out of memory (in which case unused for long time regions are freed), or rendering is finished.



It's likewise unlikely you can apply different geometry data to instances, as really that pushes the concept. but you could contain within an instance things like a morph, which you could control using other nodal inputs on a per-instance basis. It's probably more practical to just have a few base models (a few different leaf models or grass blade models) to help vary the repetition, rather than try and make one do-everything single model

Morphing/displace instance will eat memory. That's renderer must have.. It would be running hundred times slower if each time ray while traveling through region of instance, renderer has to process all points and polygons, and all applied modifiers..

serge
12-11-2009, 03:43 PM
Thanks Sensei.

So, in the example of a tree with leaves, what happens if all leaves are instances, and I 'hard-link' them for dynamics simulation? From your explanation I understand that they will eat memory as if they were 'normal' geometry, because dynamics is displacement. Is this correct?

Tobian
12-11-2009, 04:27 PM
Yes and no... If the leaves are more or less static and flat, then all you are doing is moving and rotating them, using dynamics, it's only if you then want the wind to bend each leaf, that it will eat memory, from what I understand what Sensei is saying. That said you could have a quite sophisticated animation of the tree swaying back and forth, and the leaves all moving round dynamically, with nodal controllers, and it wouldn't eat much memory at all.

That said I know with HDinstance, for example, you can use pre-baked animations, so you could have objects which are animated, and then nodally, you randomly offset the animation loop, thus helping it look a lot more complex, but still classing as instances, so you save that memory! :)

Sensei
12-11-2009, 05:03 PM
Thanks Sensei.

So, in the example of a tree with leaves, what happens if all leaves are instances, and I 'hard-link' them for dynamics simulation? From your explanation I understand that they will eat memory as if they were 'normal' geometry, because dynamics is displacement. Is this correct?

Correct. Displacement that you set in Object's Properties can displace each vertex independently, therefore it must eat additional memory for vertex buffers, and polygon normal vectors (for speeding up ray-triangle hitting routine), and several other data optimizing triangle hitting. If it's done permanently to whole part, like this happens in Motion Options window, then such thing can be done without eating additional memory. Because in this model, ray-origin and ray-direction are translated once, instead of vertexes.

I have been experimenting in TrueHair Preview renderer without data optimizing ray-polygon hitting, and results were 300% and more slower than with them.

Sensei
12-11-2009, 05:08 PM
That said I know with HDinstance, for example, you can use pre-baked animations, so you could have objects which are animated, and then nodally, you randomly offset the animation loop, thus helping it look a lot more complex, but still classing as instances, so you save that memory! :)

They shouldn't be called instances anymore, but dynamic objects or so. Their vertex data, polygon normal buffers and other data optimizing ray-triangle hitting are stored in the file. And read while ray travel region with such object. They can be even preprocessed such way, that they have data organized in kd-tree in the file, and only very small portion of file is read, not using any significant memory amount. When ray is not traveling through them enough time, memory is freed.

Intuition
12-11-2009, 05:42 PM
ooops wrong post...