June 20, 2019 at 11:02 am #16210
I know that mojo3d can copy and duplicate models, but how would you go about loading a single model and then use instances of that model (not copy, etc)
anyone have any suggestions?June 20, 2019 at 5:00 pm #16211
It is is more or less “the dark side” of scene graph architecture. This bugged me as well from time to time, only after studying the Doom2 source code I was able to figure how is done.
In that game they used sprites (aka static images or animated images) that they were rendered in a pixel buffer. Essentially having their own software renderer based on pixel plotting made things easier in that sense. Also seeing some other ports, of having a modern OpenGL renderer essentially retained the core rasterizer ideology.
In monkey, this is the same as using the mojo renderer, which is a “batch renderer”.
Essentially in terms of architecture, it means that having each sprite_id mapped to an entity_id, you could that way render by entity_id, where each entity doesn’t care about it’s sprite, only containing the correct enum of sprite_id, so the Renderer understands how to deal with it.
My best pick on this problem would be to see how to alter the rendering method of mojo3d to render with mojo, ether render to buffers and writing custom code for figuring out the z order, or perhaps creating some new modifications to mojo, to make it a 3D batch renderer.
P.S.  There might be other ports as well I haven’t looked, such as Zandorum, also I haven’t looked at Quake1 yet, which would be interesting to learn from as well.  Also I have not figured out if features like lighting or pixel effects would work correctly, I can guess that rendering to buffers is similar to the deferred rendering technique, which is based on multiple passes, in that case it works good.June 21, 2019 at 5:13 am #16212
it’s not quite the information I was after, but great to know 🙂
Instancing is where you have the data on a single model (in the vertex and index buffers) and render it more than once using instances of it with different location values.
In the cubes example (in mojo3d) the cubes are being copied (which is making another cube in the data). an instance would just make a reference to the data thus using less memory?June 21, 2019 at 9:10 am #16213
The idea behind instancing is somewhat the same as what VBO objects. Back in the early classic OpenGL versions you had the immediate mode. With introduction of vbos simply instead of iterating all the time for each vertex, simply you would pump all the data into the buffer (the gpu memory) and then simply store only a pointer (vbo id) to that data, that way your rendering would cost only 1 OpenGL call. But now if you consider that you have many models in the scene you want to render, again with instancing you can pump their positions in an array and render them all at once with only one call again.
What that means is that essentially you can
 reduce OpenGL calls: the bread and butter of gpu power is actually letting it work as much as possible independently
 optimize memory capacity: indeed loading the same model over and over again is an overkill in terms of optimizationJune 21, 2019 at 12:46 pm #16214
Thanks for that explanation.
I know what it is, but really wanted help to see if mojo3d could do it – it looks (initially) that instancing is not supported, but I will just have to keep digging into the source 🙂June 21, 2019 at 5:36 pm #16217
Take it with a grain of salt since 97.23% of the time I have no idea what I’m talking about, but I believe that’s what Mojo3D is already doing “behind the scenes” when you use entity.Copy(). I think the mesh data is stored only once in the GPU, and simply referenced by all the copies with their own unique transform matrices.
Hopefully Mark still checks this forum every once in a while and can shed some light into it.June 22, 2019 at 5:16 am #16219
Thanks for that piece of info 🙂
I’m using the first version of mojo3d (V1.1.06) so I will have to check the latest version and see what’s different inside it.
I wll have to do some checking on the vertex buffers and see what increases. but this does give me a good start 🙂June 22, 2019 at 6:11 am #16220
In mojo3d, the Model entity represents the ‘instance’ and the Model.Mesh and Model.Materials are shared by all copies of a Model, so when you copy a Model the mesh and materials are not also copied. This makes Models very cheap to copy as mojo3d only has to allocate a new Model.
The vertex/index buffers are cached in the mesh, so these also get reused when you copy a model.June 22, 2019 at 11:19 am #16221
Hi Mark 🙂
So (lets say) I have a cube. cube = Model.CreateBox( New Boxf(-1,-1,-1,1,1,1), 1, 1, 1, mat )
when I cube2 = cube.Copy()
There is only one set of cube data and vertexes. <- I think?
cube and cube are instances with their own material <- I think?
Does this hold for the initial version of Mojo3d or only the latest versions?
I’m currently hacking things to add support for a new low poly version model format.June 24, 2019 at 2:34 pm #16222
Here’s a shot of what I’m working with. it’s a new version of my 3d editor. what is really interesting is there is NO Mojo3d or 3d render being used. this is a software renderer with shader support.
It will export the models and then they will be accessible in mojo3d.June 25, 2019 at 6:57 am #16223
Wow, that’s pretty substantial… own software renderer or 3rd party? Nice look to it.June 25, 2019 at 9:30 am #16224
It’s something I’ve been building for about a moth, nothing 3rd party.
The 3d display is actually a heavily modified mojo 2d canvas. I’ts got quad views with full editing as well:
I’m just about to start transfer from software to mojo3d. all the basic stuff is now operational I just need to define the file stuffJune 28, 2019 at 10:12 am #16226
Here is a shot of the editor with the new (edited) mojo3d window in operation
Still work to do with textures, but everything is all in place now 🙂June 29, 2019 at 4:56 pm #16228
Looking good 🙂July 2, 2019 at 4:55 pm #16234
Have you figured out the mesh duplication thing when copying?
You must be logged in to reply to this topic.