View Full Version : Mesh Instancing ...
04 April 2004, 10:02 AM
Does anyone know the best way to instance models/objects in a game in an object-orientated way? Should I use a factory design pattern? :shrug:
Plus, have heard of a 'flyweight' pattern - is this what I need?
04 April 2004, 08:50 PM
This depends on the scene graph, but assuming you can add whatever custom data types you need to your engine, then create a geometry-type called "instance" that inherits all its geometry from a reference mesh. Changes to the reference mesh should produce changes to any instances that depend on the mesh for their description.
Instances generally need their own transformation settings (for translation, rotation, scaling) but they can use the reference mesh for everything else. If this isn't the right answer, please write a more specific question.
As far as doing this in an "object-oriented" fashion, this depends on the API you're using. Can you be more specific?
04 April 2004, 11:34 AM
Hi, cheers for the info.
Basically I'm trying to code a very simple C++ scene graph to use for a crowd simulation app, and was just wondering how I could code this properly, so that one mesh/skeleton could be shared for all actors.
I just thought about overloading the '=' operator to clone the object from the master object and just pass the original pointer. Do you know of any other, better deisnged methods (i.e factory method, etc)?
Is that any clearer? Hope so, just a bit hard to explain what I mean!!
04 April 2004, 09:00 PM
This largely depends on the number of instances in your crowd. The thing to consider is that each instance has to have its own transformation (position and rotation for sure, scale isn't required). The (shallow copy) override method you describe creates literal clones, and that might not be what you want for a crowd simulation?
Do you want to have a series of animations and have each instance have the exact same animation, or do you want to create a series of instances with independent animations? That's a bit more complex than literal copying.
Hope this helps.
04 April 2004, 12:37 PM
Yep, I had thought that literal copying wasn't the best way to go, but the other way I'd seen in a book was using an object 'factory' technique to manage resources and particulary mesh instancing.
To answer your questions, there will be possibily tens of thousands in the crowd, each derived from a 'master' actor with the same 'brain network' and same range of animations. Also, have seen this 'flyweight' design pattern thing - do you know if that's applicable or not?
04 April 2004, 03:01 PM
I think what you want is to have the same setup Maya does.
An "object" should consist of a transform node and a "shape" node. The transform node contains (obviously) transformation attributes, and visiblity attributes, things like that. It also points at the shape node that contains the actual object mesh data.
Then all you have to do to create an instance is create a new transform node and point it at an existing shape node.
How exactly you code this is academic. I suggest the easiest way would just be to write getInstance() functions for your nodes.
This is a seperate point from things like reference counting, which it sort of sounds like you're talking about in your post as well.
I think you're going to need to create and link a whole bunch of different objects to achieve what you want. After all, each actor needs its own brain, but they could all theoretically reference the same skeleton and mesh data.
04 April 2004, 04:39 PM
Cheers. That's kind of what I was thinking of, but was just unsure of how to design this (using various design patterns). As per usual I'm more concerned about the design and less of the practical coding!!
In relation to what each instance needs, I agree that each actor needs to reference only one mesh & animations, but could I have just one central brain node definition with each instance only storing its current state? Not sure about what's best to do.
01 January 2006, 03:00 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.