[feature request] Additions to MeshBuffers

You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
greenya
Posts: 1012
Joined: Sun Jan 21, 2007 1:46 pm
Location: Ukraine
Contact:

Re: [feature request] Additions to MeshBuffers

Post by greenya »

Hello.

I would suggest to add additional overloadings to drawVertextPrimitiveList() and draw2DVertextPrimitiveList(), which takes scene::VertexBuffer* and scene::IndexBuffer*. We don't really need to send primitiveCount for this overloadings because user can always call indexBuffer->setUsed(anySmallerValueThanCurrentlyAllocated) and the values will not be lost after, and after the drawing he can setUsed() back to old value, the only thing he can't draw couple of primitives from the middle of the buffer, which is easily possible with drawVertextPrimitiveList() with void*-versions -- and i really do find this as a good feature (a lot flexibility, we can store everything in the single large chunk of buffer and have index all stuff from it and draw each of them separately with any material settings and so on -- this makes drawing and managing a bit complex but make serialization and deserialization fairly simple for any scene complexity).

Anyway, back to the topic, next code i made for my .NET wrapper, it allows to draw vertex and index buffer pair, which are insanely easy to interact (comparing to void* :)) and are built on core::array<T> which can handle auto allocation for more items -- this is really cool for drawing anything that is beyond triangles (since Mesh is very good at it too).

Code: Select all

void VideoDriver::DrawVertexPrimitiveList(Scene::VertexBuffer^ vertexBuffer, Scene::IndexBuffer^ indexBuffer, Scene::PrimitiveType pType)
{
    LIME_ASSERT(vertexBuffer != nullptr);
    LIME_ASSERT(indexBuffer != nullptr);
 
    scene::IVertexBuffer* vb = vertexBuffer->m_VertexBuffer;
    scene::IIndexBuffer* ib = indexBuffer->m_IndexBuffer;
 
    if (vb->size() == 0 || ib->size() == 0)
        return;
 
    unsigned int primCount = calculatePrimitiveCount(ib->size(), pType);
 
    m_VideoDriver->drawVertexPrimitiveList(
        vb->pointer(),
        vb->size(),
        ib->pointer(),
        primCount,
        vb->getType(),
        (scene::E_PRIMITIVE_TYPE)pType,
        ib->getType());
}
I would suggest for Irrlicht the function interface should be:

Code: Select all

virtual void drawVertexPrimitiveList(
                const scene::IVertexBuffer* vertexBuffer,
                const scene::IIndexBuffer* indexBuffer,
                u32 primCount, // we left this argument to be consistent with other drawVertexPrimitiveList()s, but as i described above, we do not have that flexibility which void*s gives (starting from any position of the buffer)
                scene::E_PRIMITIVE_TYPE pType=scene::EPT_TRIANGLES) =0;
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Re: [feature request] Additions to MeshBuffers

Post by hybrid »

Didn't check the patch yet, but since it's missing in the list: What about recalculateNormals? For now, every mesh buffer can be used with this method, and it works correctly. Now, lines are probably out, while quads need a completely new way to handle the calculations. And tri-strips need an algorithm to create the proper faces on the fly. Now you.
gerdb
Posts: 194
Joined: Wed Dec 02, 2009 8:21 pm
Location: Dresden, Germany

Re: [feature request] Additions to MeshBuffers

Post by gerdb »

hi, @hendu since irrlicht was developed for d3d first ( which causes the messed up drawMeshBuffer mechanism) i guess it kinda fit.

@hybrid: Do you mean the recalculateNormals from CMeshManipulator?

i know it has to be adopted bigtime, but the assumption all shapes i like to render are triangles, is simply false and the class needs therefore a big revision. ( not my fault, but i will stick my nose into ).

EDIT: But its like the SoftwareDrivers, irrlicht simply cant handle other primitives than EPT_TRIANGLES well, and the addition to trunk of my patch should not rely on such improvements. If somebody draws lines, he simply cannot use a function like recalculateNormals without messing up anything ( for now )
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: [feature request] Additions to MeshBuffers

Post by Nadro »

@greenya
Similar interface for your proposal is already available in shader-pipeline branch (this branch will be part of Irrlicht v2.0)
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: [feature request] Additions to MeshBuffers

Post by CuteAlien »

Original patch lost by now unfortunately (should have been on patch-tracker...). But based my patch on what was posted in this thread. Didn't change any existing interfaces - so no 'Ex' functions. Simply some stuff added.
Other problems like missing support for other primitive types in mesh-manipulator simply ignored. They won't break existing code. And I added some documentation to warn about stuff that won't work.
So - svn trunk r5425 has now meshbuffers with different primitive types for those who need it.

Example using it: https://bitbucket.org/mzeilfelder/irr-p ... ew-default
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Post Reply