Vertex buffers and other objects

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Saturn
Posts: 418
Joined: Mon Sep 25, 2006 5:58 pm

Post by Saturn »

@EmmanuelD: I've not read your second proposal yet. When I do, I'll comment on it.

@Hybrid: I'm not sure I understand what you mean in your post. What does "some simple vertex array and buffer properties" mean?
I agree, that exposure of the underlying API-interfaces is a bad idea. Did someone propose this?

@Spintz: Imho your implementation doesn't go far enough. It doesn't allow a free format and it still uses the differen fixed SVertex-Types.
I've basically the same objections, EmmanuelD voiced in his post.

Here is a small mock-up I just made up, so no all-things-figured-out proposal...

Code: Select all

typedef enum {EVET_POSITION, EVET_NORMAL, EVET_TEXCOORD_2D, ...} VertexElementType;
// SXXX because it can be implemented in a header and be used for all
// drivers..
class SVertexDefinition
{
public:
    u8 getNumElements() const;

    VertexElementType getElementType(u8 elementIndex) const;
    u8 getElementOffset(u8 elementIndex) const;
    u8 getOffsetByType(VertexElementType) const;

    u8 getSize() const; // in byte for the whole vertex

    void clear();
    void addElement(VertexElementType)

    bool operator==(const SVertexDefinition& ) const; // important for checking buffer compatiblity
    ....
private:
    // implementation details, for instance a single or a pair of arrays for
   //  type and offset.
};

class IVertexBuffer : public IUnknown
{
public:
    virtual SVertexDefinition* getVertexDefinition() const;
    virtual void* lock();
    virtual void unlock();
    virtual u32 getSize() const;
};
I hope this mock-up is self-explaining. lock() just gives a mem pointer. This can either be into a mapped hardware buffer in OGL/Dx-Renderer or some plain memory in the software renderers. Same interface.
Of course you can still cast the void* to SVertex*, if your layout matches the accordant E_VERTEX_TYPE.

One might argue, that thus irrlicht will get more difficult to use, but I don't believe this to be true. Multiple reasons: First, this affects only the deeper end of irrlicht. The beginner doesn't come in touch with vertex buffers really, as he uses the ISceneNode interfaces rather than direct buffers. Users that do are used to handle pointers themself.
Second, while this is less safe than SVertex, it is in the end easier to program with. You can now handle all vertex types the same. If some element type you would handle is not there, you ommit it, if all you want to do is to update position, then you can do it for all thinkable vertex formats without distinguish between them.
EmmanuelD
Posts: 25
Joined: Thu Aug 24, 2006 8:34 am
Location: Right in front of Dagoth Ur
Contact:

Post by EmmanuelD »

hybrid wrote:Maybe the public interface should indeed just use some simple vertex array and buffer properties instead of giving access to the full-blown hardware buffer mess. Each driver can then create the internal representation necessary. I'm not sure if there is a chance to make this somewhat performant and portable, but just exposing the D3D or OpenGL interface in the Irrlicht namespace should definitely by avoided.
I also don't want to expose anything of the OGL or D3D interface in the irrlicht namespace. I want to expose an abstraction of these interface because such abstraction is currently lacking. My goal in this proposal is to use the same exact philosphy that lies behind the texture implementation - nothing more, nothing less. The difference is that I want to be able to specify any arbitrary vertex format, as long as it is supported by the underlying driver.

As of today, there are a number of techniques that can't be implemented using irrlicht, and my proposal (I should say "our" - I'm not alone in this project) just want to open some doors.

What I can do is to implement this proposal and then you'll have some stuff to play with. That way you'll be able to see whether the base idea is good or not - or if it needs to be changed a bit.

Regards,
-- Emmanuel D.
Spintz
Posts: 1688
Joined: Thu Nov 04, 2004 3:25 pm

Post by Spintz »

I honestly didn't read enough, I saw Hybrid's comment about IIndexBuffers not supporting hardware, but they do, in IrrSpintz, just data isn't stored in IIndexBuffer.

I'm also missing a lot, because it seems this thread was a continuation of an old thread, but I've no clue what led up to this discussion.

Anyways, I have no use for variable Vertex Buffers. I've been planning on adding 1 or 2 more vertex formats, but I have no plans on ever needing a full blown variable vertex format.
Image
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

I think I thought about something more like Spintz' version. What is basically required for Irrlicht is to store the meshes on the gfx card and recall it from there. All the fancy vertex streams will not add that much performance anymore and should be kept in the background as much as possible. I've tried to work through Ogre's vertex stream implementations when working with the Ogre loader. And I was really ***** ***** by this code (not that it's bad, it's just not what you want to use on a daily basis :wink: )
The problem with exposing the low-level interfaces is that methods using the normal Irrlicht interface (e.g. some user provided mechanism transforming meshes) won't work anymore. That's also why the new render primitives are not used by default. They will probably back up the triangle render methods at some time, but only if the public interface provides all data such that algorithms can be implemented really easy.
EmmanuelD
Posts: 25
Joined: Thu Aug 24, 2006 8:34 am
Location: Right in front of Dagoth Ur
Contact:

Post by EmmanuelD »

hybrid wrote:I think I thought about something more like Spintz' version. What is basically required for Irrlicht is to store the meshes on the gfx card and recall it from there. All the fancy vertex streams will not add that much performance anymore and should be kept in the background as much as possible. I've tried to work through Ogre's vertex stream implementations when working with the Ogre loader. And I was really ***** ***** by this code (not that it's bad, it's just not what you want to use on a daily basis :wink: )
Although it is powerfull, Ogre is some kind of strange beast from a design point of view. That's why we chosed irrlicht ;)
hybrid wrote: The problem with exposing the low-level interfaces is that methods using the normal Irrlicht interface (e.g. some user provided mechanism transforming meshes) won't work anymore. That's also why the new render primitives are not used by default. They will probably back up the triangle render methods at some time, but only if the public interface provides all data such that algorithms can be implemented really easy.
I must admit (with shame) that I overlooked these points. Since we have to implement vb and ib in this way, I will give a look to how it integrates with the other irrlicht components (animators, selectors and so on). I agree that if the integration with these components is not easy, it will be a major problem.
I'll let you know about any progress and problems I find in my proposal.

Regards,
-- Emmanuel D.
Post Reply