Irrlicht Engine

Great to see progress here, thanks
On texture matrices uploading: that feature being rarely used (but we use it indeed, for animating textures), I think you should not upload it when the matrix is identity. Ideally I think you should detect when the matrix changed and just upload in that case...

Hendu >> do you know which cards those are? (I suppose some Intel chips?) So the philosophy is to only expose something that would work everywhere? That severely restricts the feature set Irrlicht can cover, then, and it wouldn't push the engine forward...

I think I'm in a good position to understand how it feels to lack time, no worries :) I was just checking after some days if the conversation was ended or not. I didn't expect to get answers anymore, sorry if I didn't wait long enough. The "offsetof" thing isn't really important to be hone...

Ping? Nothing new here?

No news on this topic then? One other thing: in the SuperTuxKart project, we had to set _IRR_MATERIAL_MAX_TEXTURES_ in IrrCompileConfig.h to a bigger value (we switched from 4 to 8). Is it possible to report this modification to trunk? For now we have our own version of Irrlicht, and as time goes we...

It seems that's right, offsetof() is not defined for non-POD types... However in practice, as long as there are no virtual functions or multiple inheritance, the layout will be standard, and offsetof() will certainly work. For the record, Visual Studio defines it this way:   #ifdef  _WIN64 #define o...

On the remark on formatting, I understand, will try to avoid that in the future.

Can I expect my patch to reach trunk?

Hi, I'm occasionally working on the SuperTuxKart project, that uses Irrlicht, and there are some modifications we are making to 1.8 there, that I think would be worth reporting upstream. I'll start with a simple patch that replaces raw values for the buffer offset in glXXXPointer() functions with us...

Nadro >> I agree.
hybrid >> would you be ok if the user was required to provide his own vertex shader for using hardware skinning ?
IMO the best solution would be to give an example shader to the user, that would use a small set of easily reusable functions.

Yup, and as I said, I'm a bit worried about the vertex shader thing (i.e. handling everything that is done in the FFP, which includes lighting with a possibly varying number of lights...).
I think that is where the real challenge is, but tell me if I'm wrong.

I believe all the guys who needed hw skinning already have found their way to do it anyway.

I doubt that, at least that's not the case for STK, and that's the job of the engine anyway...

Hmm ok, so I will try to provide a DX9 implementation then... Yes it only requires a vertex shader, but if you use vertex lighting (which the fixed function pipeline does by default IIRC, right?) then it has to be implemented in the vertex shader. Now, think of using vertex lighting with a number of...

Ok, thanks for the quick answer ^^ Would it be ok if I add fixed vertex format(s) that support hardware skinning, while waiting for a flexible vertex format-based approach? And if yes, I have 3 questions: - should I add the 3 required variants (Standard, 2TCoord and Tangents), or would it be ok if I...

Hi all, I am a contributor to the game SuperTuxKart, which is based on Irrlicht, and I have done some attempts at implementing hardware skinning, as skinning has been identified as the biggest bottleneck in STK's performance. I primarily took my inspiration from this thread: http://irrlicht.sourcefo...

I think materials should be exported correctly, but I didn't verify...

I'll try to write my own exporter for the X file format, if I manage to make it work I'll tell you ^^