mojo3d model instancing anyone?

About Monkey 2 Forums Monkey 2 Programming Help mojo3d model instancing anyone?

This topic contains 18 replies, has 6 voices, and was last updated by  AdamStrange 1 week, 3 days ago.

Viewing 15 posts - 1 through 15 (of 19 total)
  • Author
  • #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?



    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. [1] 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. [2] 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.



    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?



    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
    [1] reduce OpenGL calls: the bread and butter of gpu power is actually letting it work as much as possible independently
    [2] optimize memory capacity: indeed loading the same model over and over again is an overkill in terms of optimization



    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 πŸ™‚



    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.



    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 πŸ™‚


    Mark Sibly

    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.



    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.



    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.

    Screenshot 2019-06-24 at 15.30.38.png



    Wow, that’s pretty substantial… own software renderer or 3rd party? Nice look to it.



    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:

    Screenshot 2019-05-28 at 07.19.31

    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 stuff



    Here is a shot of the editor with the new (edited) mojo3d window in operation

    Screenshot 2019-06-28 at 11.07.08.png

    Still work to do with textures, but everything is all in place now πŸ™‚



    Looking good πŸ™‚



    Really interesting.

    Have you figured out the mesh duplication thing when copying?

Viewing 15 posts - 1 through 15 (of 19 total)

You must be logged in to reply to this topic.