Mojo3D Vertex animation/morphing – how?

About Monkey 2 Forums Monkey 2 Programming Help Mojo3D Vertex animation/morphing – how?

This topic contains 11 replies, has 3 voices, and was last updated by  Diffrenzy 1 year, 6 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #10927

    Diffrenzy
    Keymaster

    I’d like to morph between two (or more) sets of vertices, keeping the triangles  intact.

    I’m adding the vetices myself, so I haver their indexes.

    How would I go about this?

    #10936

    cocon
    Participant

    I tried something but I did not get any results, whoever wants to continue the search I will mention the details.

     

    I went to mojo3d.graphics.mesh and I added this method (after the TransformVertices):

     

    Then I did a rebuild:

     

    And then at the “makequad” example I added this on the update loop.

     

     

    Unfortunately I did not get any results, but this is how it should be done. Once I get more familiar with the inner workings of the Mojo3D I will know better, but this is the first time I every looked at it. 🙂

    #11005

    Mark Sibly
    Keymaster

    Ok, finally got around to doing something here.

    The latest develop branch includes new versions of VertexBuffer and IndexBuffer and a new ‘Renderable’ entity class.

    There’s also a ‘morpher.monkey2’ in mojo3d/tests dir that shows you how to create your own renderable entity classes. It’s hopefully quite sensible:

    Basically, renderers need to implement OnRender() which is passed a ‘RenderQueue’ which you can add render ops to.

    A render op is basically a combination of material,instance,vertexbuffer,indexbuffer and draw count etc.

    Batching render ops like this allows for multiple render passes if necessary without having to call OnRender multiple times. It also potentially allows for ‘state sorting’ (doesn’t do that yet), better instancing using GL extensions (doesn’t do that yet either), and potentially culling. The render ops are also used to render shadow maps if Renderable.CastsShadow is true.

    Renderable is now used by Model, Sprite and ParticleSystem, although there’s a big kludge in there for Sprites.

    OnRender is called once per camera, and will probably get a camera param at some point. It would also be possible to have a ‘baked’ renderqueue that was camera independant and didn’t have to be rebuilt all the time.

    Note that custom Renderers like this must manage vertex/index buffers themselves (as above), although ‘helper’ classes could easily be added. Renderer is as simple as possible.

    I also modified/simplified vertex/index buffers quite a bit. They are now (mostly) statically sized and ‘lockable’. There’s a convience Resize() in there, but they no longer act like mini-stacks, ie: no more AddVertices. Mesh should be pretty much the same though, so as long as you’ve been using tha6t you should be OK. Didn’t have to change meshprims.monkey2 anyway.

    #11012

    Diffrenzy
    Keymaster

    Wow! That is so elegant, and it just works! 😀

    In my own code, I get a “Memory Access Violation” in Mesh->Method AddVertices( vertices:Vertex3f Ptr,count:Int )

    at libc.memcpy( _vertices.Data.Data+first*Vertex3f.Pitch,vertices,count * Vertex3f.Pitch )

    should I make a reproducable example, or is this expected?

    #11013

    Mark Sibly
    Keymaster

    should I make a reproducable example, or is this expected?

    Example please, just had a quick look and can’t see anything obviously wrong.

    #11014

    Diffrenzy
    Keymaster

    Probably my code then, something that did not use to bomb, will investigate.

    #11017

    Diffrenzy
    Keymaster

    I think I reproduced it:

    #11018

    Diffrenzy
    Keymaster

    .

    #11027

    Mark Sibly
    Keymaster

    Fixed in develop branch.

    #11046

    Diffrenzy
    Keymaster

    Confimed working.:-)

    I’m probably being dim, but I don’t get why you don’t have to multiply by pitch, for the destination address.

    If Local first:=_vertices.Length gets the number of elements, and memcpy needs a pointer to the destination address in bytes, your original code seems correct.

    #11051

    Mark Sibly
    Keymaster

    I’m probably being dim, but I don’t get why you don’t have to multiply by pitch, for the destination address.

    Good question!

    Like c/c++, monkey2 pointer addition/subtraction takes the size of the data actually pointed to into account. So ‘p+10’ where p is an int ptr will actually add 40 to p, as ints are 4 bytes long. Ditto p[10] will reference the memory at address ‘p+40’ (using [ ] with pointers is just a special type of pointer addition).

    However, libc.memcpy doesn’t know anything about types, it just takes void ptrs and a byte size. Monkey2 ‘fixes’ the pointer params, but not the size so you need to premultiply it by pitch.

    It might be an idea to add some ‘typed’ memcpys somewhere, eg:

    This way, you dont’t have to premultiply count by pitch, so the SetVertices code is even simpler.

    #11060

    Diffrenzy
    Keymaster

    Thanks, I get it now, this is Pointer arithmetics.

    Your ‘typed’ memcpys seems nice!

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.