Page 1 of 2

[feature request] Additions to MeshBuffers

Posted: Sun Mar 18, 2012 6:02 pm
by gerdb
hi, im currently working on a 3ds model

i can open it in irrlicht, but it seems

1. that the amount of loaded meshbuffers is incorrect, i got an amount of buffers (5) the same as textures, but there are many more buffers
sharing the same texture (material) -> are all buffers using the same material combined together?

2. i like to have names for meshbuffers, so i can distinguish them.

3. adding the property E_PRIMITIVE_TYPE to MeshBuffer so it can contain Points and Lines and all other Primitives already supported by irrlicht.

4. redevelop the drawMeshBuffer and drawVertexPrimitiveList functions, i really dont know why you need a u32 primCount, when the function can
calculate it by itself, depending on the primitive type. ok maybe you dont want to draw the whole meshbuffer, but this event is much less common then drawing lines or points, you can also control the amount of prims with the indexcount.

and as i see there is already a big switch distinguishing the drawCalls depending on the primitive type, so why not deleting this all and give the user (me) more flexibility handling meshes.

pls dont tell me irrlicht needs triangles to dont mess up, thats really an issue with irrlicht, not with my proposal.

all shape outlines need EPT_LINES etc, i really cant draw all different shapes with triangles, really really not.

end.

Re: [feature request] Additions to MeshBuffers

Posted: Sun Mar 18, 2012 6:57 pm
by REDDemon
1) probably yes. Seems more an issue of the exporter of your modelling tool. Irrlicht can decide to split a mesh into more meshbuffers if it is to big. But merging mesh buffers is not done by irrlicht (unless you explicity require it using the Lonesome's mesh combiner).

2) you already have names. IMeshBuffer inherit from IReferenceCounted (wich has the ability to set a debug name that you can use if you need).

4) primCount refers to the number of triangles(of course if your primitive is triangles) not to the number of vertices for each primitive (wich is obviously 2 for lines and 3 for triangles),

can you post some example method to show what you mean?

Re: [feature request] Additions to MeshBuffers

Posted: Sun Mar 18, 2012 9:17 pm
by gerdb
hi,

my problem is this function

void drawMeshBuffer( scene::SMeshBuffer* buffer );

that has no idea about what i really want to get rendered. instead on the one side i can compensate this

with a new function

void drawMeshBufferEx( scene::SMeshBuffer* buffer, scene::E_PRIMITIVE_TYPE primitiveType = scene::EPT_TRIANGLES);

BUT
--> SMeshBuffer already determines EIT_16BIT
--> SMeshBuffer already determines EVT_STANDARD
--> SMeshBuffer already determines getVertices()
--> SMeshBuffer already determines getVertexCount()
--> SMeshBuffer already determines getIndices()
--> SMeshBuffer already determines getIndexCount()
--> but it does not determine EPT_ANYTHING

as you can see in function

driver->drawVertexPrimitiveList(
(void*)&buffer->Vertices[0], buffer->Vertices.size(),
(void*)&buffer->Indices[0], primitiveCount,
vertexType, primitiveType, indexType);

all parameters except the one E_PRIMITVE_TYPE are stored in SMeshBuffer

which would lead to the automatic calculation of primitiveCount

-> that would lead to the complete senseless existences of drawVertexPrimitiveList, you just need to call drawMeshBuffer, as it does the primitive calculation
anyway.

my function does the complete opposite of what irrlicht does, to compensate the stupid drawMeshBuffer function, which does not take E_PRIMITIVE_TYPE into account.

Code: Select all

 
inline void drawMeshBufferEx( IVideoDriver* driver, scene::SMeshBuffer* buffer, scene::E_PRIMITIVE_TYPE primitiveType = scene::EPT_TRIANGLES,
        E_VERTEX_TYPE vertexType = EVT_STANDARD,
        E_INDEX_TYPE indexType = EIT_16BIT)
{
        if (!buffer)
                return;
 
        u32 primitiveCount = 0;
        switch (primitiveType)
        {
                case scene::EPT_POINTS:
                        primitiveCount = buffer->Indices.size();
                        break;
                case scene::EPT_LINE_STRIP:
                        primitiveCount = buffer->Indices.size()-1;
                        break;
                case scene::EPT_LINE_LOOP:
                        primitiveCount = buffer->Indices.size()-1;
                        break;
                case scene::EPT_LINES:
                        primitiveCount = buffer->Indices.size()/2;
                        break;
                case scene::EPT_TRIANGLE_STRIP:
                        primitiveCount = (buffer->Indices.size()-2)/3;
                        break;
                case scene::EPT_TRIANGLE_FAN:
                        primitiveCount = (buffer->Indices.size()-2)/3;
                        break;
                case scene::EPT_TRIANGLES:
                        primitiveCount = buffer->Indices.size()/3;
                        break;
                case scene::EPT_QUAD_STRIP:
                        primitiveCount = (buffer->Indices.size()-2)/4;
                        break;
                case scene::EPT_QUADS:
                        primitiveCount = buffer->Indices.size()/4;
                        break;
                case scene::EPT_POLYGON:
                        primitiveCount = buffer->Indices.size()-1;
                        break;
                case scene::EPT_POINT_SPRITES:
                        primitiveCount = buffer->Indices.size();
                        break;
                default:
                        primitiveCount = 0;
                        break;
        }
 
        driver->setMaterial(buffer->getMaterial());
        // driver->setTransform(ETS_WORLD, );
 
        driver->drawVertexPrimitiveList(
                (void*)&buffer->Vertices[0], buffer->Vertices.size(),
                (void*)&buffer->Indices[0], primitiveCount,
                vertexType, primitiveType, indexType);
}
 
} // END NAMSPACE VIDEO
} // END NAMSPACE IRR
 
 
the whole thing is, that i cant use IMeshSceneNode without this information, and therefore always need to call drawVertexPrimitiveList, which pollutes
my while loop, and i have to delete the MeshBuffer by myself, which also pollutes my App.

when i just could register the IMeshSceneNode and it would calculate the primitiveCount for itself, all different Shapes would be possible

from

Code: Select all

main
{
      SMeshBuffer* noTriangles;
      while
      {
           drawAll()
           drawVertexPrimitiveList(noTriangles)
      }
     delete noTriangles;
}
to

Code: Select all

main
{
     IMeshSceneNode* noTriangles
     while
     {
        drawAll
     }
     // no deletion needed as the scenemanager does it
}
also possible would one new class IAdvancedMeshSceneNode(IMesh*, E_PRIMITIVE_TYPE)

instead of IMeshSceneNode (IMesh*) to give the one tiny but all essential information E_PRIMITIVE_TYPE

Re: [feature request] Additions to MeshBuffers

Posted: Sun Mar 18, 2012 11:22 pm
by hybrid
a) drawMeshBuffer takes IMeshBuffer, not SMeshBuffer. So nothing is fixed.
b) if you find possibilities for all the functions that take IMeshBuffer to handle all primitive types we can start thinking about doing what you propose. Until then it's not possible.

Re: [feature request] Additions to MeshBuffers

Posted: Mon Mar 19, 2012 12:42 am
by gerdb
hi, really cant believe that it was that easy, this svn is just great.

QUESTION does the patch.diff also work for 1.7.3, i diffed against trunk 4108

Lib compiled fine in Debug & Release mode under Linux

my first svn patch, so dont laugh :twisted: :

adds getter/setter + field E_PRIMITIVE_TYPE PrimitiveType to some classes (IMeshBuffer, IDynamicMB, SSKinMeshbuffer, ...)

adds the big switch to Drivers -> did not find in D3D8Driver, is there any !?!?

so there are really no big changes, but they happen to be the very core of irrlicht :mrgreen:

QUESTION: i always did case EPT_TRIANGLES: as first statement in switch -> does this accelerate the switch in most cases?

Patch:
http://benjaminhampe.be.ohost.de/Irrlic ... hampe.diff

From COpenGLDriver::renderArray

Code: Select all

 
                case scene::EPT_LINE_STRIP:
                        glDrawElements(GL_LINE_STRIP, primitiveCount+1, indexSize, indexList);
                        break;
                case scene::EPT_LINE_LOOP:
                        glDrawElements(GL_LINE_LOOP, primitiveCount, indexSize, indexList);
                        break;
                case scene::EPT_LINES:
                        glDrawElements(GL_LINES, primitiveCount*2, indexSize, indexList);
                        break;
                case scene::EPT_TRIANGLE_STRIP:
                        glDrawElements(GL_TRIANGLE_STRIP, primitiveCount+2, indexSize, indexList);
                        break;
                case scene::EPT_TRIANGLE_FAN:
                        glDrawElements(GL_TRIANGLE_FAN, primitiveCount+2, indexSize, indexList);
                        break;
                case scene::EPT_TRIANGLES:
                        glDrawElements(GL_TRIANGLES, primitiveCount*3, indexSize, indexList);
                        break;
                case scene::EPT_QUAD_STRIP:
                        glDrawElements(GL_QUAD_STRIP, primitiveCount*2+2, indexSize, indexList);
                        break;
                case scene::EPT_QUADS:
                        glDrawElements(GL_QUADS, primitiveCount*4, indexSize, indexList);
                        break;
                case scene::EPT_POLYGON:
                        glDrawElements(GL_POLYGON, primitiveCount, indexSize, indexList);
                        break;
        }
 
i really dont understand why you first calculate a primitiveCount, give that this function, and then recalculate the indexCount from it again?

--> why not just call glDrawElements with MeshBuffer->getIndexCount() and the switch(Meshbuffer->getPrimitiveType()) ?????

ROOT of EVIL: Microsoft

i guess, who startet developing irrlicht, startet with D3D9 Driver, that actually uses this primCount in there drawCalls (*lol*)
so why do we need this Driver anyhow? Is d3d any faster than ogl? (not including double calculations for ogl)

pls test and verify that it works, i compile all the examples tomorrow and test.

Re: [feature request] Additions to MeshBuffers

Posted: Wed Mar 27, 2013 3:09 pm
by gerdb
Hi, id like to ask if theres any progress here?

Re: [feature request] Additions to MeshBuffers

Posted: Wed Mar 27, 2013 6:35 pm
by CuteAlien
No progress, sorry.

Re: [feature request] Additions to MeshBuffers

Posted: Wed Mar 27, 2013 11:39 pm
by hybrid
As I said, we cannot change this as suggested. What about merging a quad buffer with a line_strip buffer? What is the result? What about the mesh manipulators? They won't handle a thing of this proposed addition. It is simply not possible.

Re: [feature request] Additions to MeshBuffers

Posted: Thu Mar 28, 2013 6:24 pm
by gerdb
Hi,

first of all my most important feature request is the addition of E_PRIMITVE_TYPE to the MeshBuffer classes,

that wont break anything (imho), its just a new member-var not being used by current irrlicht-functions.

Also adding quads with lines, etc, make no sense of course and should lead to the immediate return from the function.

i.e.

Code: Select all

bool addBuffer( IMeshBuffer* one, IMeshBuffer* two)
{
     if (one->getPrimitiveType() != two->getPrimitiveType())
          return false;
}
The most important advantage will be, that the MeshBuffer could render itself, because it has all needed information directly within.

i.e.

IMesh* linePath = createLinePath();
IMeshSceneNode* node = smgr->addMeshSceneNode( mesh, ....)
mesh->drop();

now the MeshSceneNode can be rendered and deleted by scenemanager without any more user/programmer interaction.

I'd say the advantages >> disadvantages

Re: [feature request] Additions to MeshBuffers

Posted: Fri Mar 29, 2013 8:07 am
by gerdb
Sry, i forgot, besides the MeshBuffer classes the CMeshSceneNode class has to be adapted/changed in its renderfunction, that would be the drawMeshBufferEx function from above, if you dont like to completly rewrite all videodrivers,

Id say, i make a patch for MeshBuffers and MeshSceneNode ( nothing else ) and you can see for yourself, if theres anything not working ( like TriangleSelectors, Anims or whatever maybe broken ), ok?

Re: [feature request] Additions to MeshBuffers

Posted: Sat Mar 30, 2013 10:20 am
by hybrid
No, addMeshBuffer is not working as expected if it rejects all those combinations. Instead, it should use a minimal base primitive and convert. Which is triangle, as it is now already. So you need a proper conversion mechanism which works transparently for the user and do things as expected.
Then, all functions working on meshbuffers or meshes expect the base type to be triangles. If you put any other type in there, most things will fail. It it inacceptable, that the manipulators and converters cannot handle a major part of the meshbuffers in future. addMeshBuffer is after all just one special example of such functions.
Hence, we can only add this feature if all functions do support this additional attribute and work properly.

Re: [feature request] Additions to MeshBuffers

Posted: Sat Mar 30, 2013 7:41 pm
by gerdb
Hi, thx for your patience,

i understand that many functions wont work with lines, line_loops, line_strips and quads.

But do they have to?

The thing with triangle_strip and triangle_fan and quads can be implemented, of course not with lines, points and such.

Many functions within CMeshManipulator make no sense with lines, and could therefore never work.

I make a SceneNode that can carry other shapes than only triangles to see what can be gained. Would that be added to irrlicht if it works in meaningful cases?

I think i call it CFlexibleMeshSceneNode or CAdvancedMeshSceneNode, any suggestions for the name, im really not that creative in english language.

Also i like to add functions to GeometryCreator that take a E_PRIMITIVE_TYPE parameter to create the shapes based on other types, would that allowed to be added to trunk, if it works right with EPT_TRIANGLES shapes?

@admins: I know irrlicht is first of all thought for games, and do understand your arguments.

I already tried to creates lines out of triangles, that seem to work, but lots of extra calculation, also points would consist of triangles too, my createCircleMesh() already does this. It has advantage when it comes to texturing, but has big disadvantages when i just want to graph some scientific data with millions of points and lines.

thx, and happy easter to you all

Re: [feature request] Additions to MeshBuffers

Posted: Tue Apr 02, 2013 1:38 pm
by hybrid
Yes, having a general primivtive type scene node would be no problem. It must not be derived from mesh scene node, though, at least as long as we don't support a general transformation from any type to triangles. But having a simple interface for these special meshes is ok in general. It just must not interfere with the basic interface of IMesh and IMeshBuffer.

Re: [feature request] Additions to MeshBuffers

Posted: Wed Apr 17, 2013 3:02 pm
by gerdb
Hi, i got the patch now (guess i wrote it twice),

its really simple,

http://benjaminhampe.be.ohost.de/Irrlic ... patch.diff

1# adds setter + getter for E_PRIMITIVE_TYPE to IMeshBuffer interface
2# adds attribute E_PRIMITIVE_TYPE PrimitveType to classes CMeshBuffer<T>, SSkinMeshBuffer, CDynamicMeshBuffer and initializes to EPT_TRIANGLES
3# adds method drawMeshBufferEx to CMeshSceneNode to render different kind of PrimitiveTypes, the switch starts with EPT_TRIANGLES for the common case

this enables my better GeometryCreator functions ( not published yet ) to either draw filled circles/ellipses/rects (EPT_TRIANGLES) or their outlines (EPT_LINE_LOOP)
decided by a simple boolean within the function-paramlist.

pls tell me where is can break anything, i found nothing.

I really hope you guys add this to trunk,

thx in advance

Re: [feature request] Additions to MeshBuffers

Posted: Wed Apr 17, 2013 3:14 pm
by hendu
I really hate the Ex naming. It reminds me of WinAPI.

/carry on