Irrlicht Wrapper for 3D games and applications

[Frank Dodd]

Hello Super_castle,

The easiest way to do that is to create the model of your armature with the point of the hinge at the origin (0.0, 0.0, 0.0). Here is an example, the left set of cubes have their origin in their centres, the right set of cubes have their origins at the bottom edge.

Code: Select all

'' ----------------------------------------------------------------------------
'' Wiggling stacks of cubes
'' ----------------------------------------------------------------------------

'' ////////////////////////////////////////////////////////////////////////////
'' Includes for extension libraries
#include "IrrlichtWrapper.bi"

'' ////////////////////////////////////////////////////////////////////////////
'' global variables

' irrlicht objects
DIM MeshCentre as irr_mesh
DIM MeshOffset as irr_mesh
DIM MeshTexture as irr_texture
DIM OurCamera as irr_camera
DIM i as Integer
DIM LeftNodes(0 to 7) as IRR_NODE
DIM RightNodes(0 to 7) as IRR_NODE
DIM LastLeftNode as IRR_NODE
DIM LastRightNode as IRR_NODE
DIM CubeRotation as double


'' ////////////////////////////////////////////////////////////////////////////
'' GDB debugger main() function

' -----------------------------------------------------------------------------
' start the irrlicht interface
IrrStart( IRR_EDT_OPENGL, 600, 600, IRR_BITS_PER_PIXEL_32, _
        IRR_WINDOWED, IRR_SHADOWS, IRR_IGNORE_EVENTS )

' set the window caption
IrrSetWindowCaption( "Wiggling Cubes" )

' a mesh is created from an array of types called vertices that define a point
' in space. and an array of indices to these vertices that are grouped into
' threes to create triangles that form the mesh

DIM vertsCentre(0 to 7) as IRR_VERT => _
                                 {(-5.0,-10.0,-5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,1.0), _
                                  (-5.0, 10.0,-5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,0.0), _
                                  ( 5.0, 10.0,-5.0, 0.0,0.0,0.0, &h00FFFFFF, 1.0,0.0), _
                                  ( 5.0,-10.0,-5.0, 0.0,0.0,0.0, &h00FFFFFF, 1.0,1.0), _
                                  (-5.0,-10.0, 5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,0.0), _
                                  ( 5.0,-10.0, 5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,1.0), _
                                  ( 5.0, 10.0, 5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,0.0), _
                                  (-5.0, 10.0, 5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,1.0)}

DIM vertsOffset(0 to 7) as IRR_VERT => _
                                 {(-5.0,  0.0,-5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,1.0), _
                                  (-5.0, 20.0,-5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,0.0), _
                                  ( 5.0, 20.0,-5.0, 0.0,0.0,0.0, &h00FFFFFF, 1.0,0.0), _
                                  ( 5.0,  0.0,-5.0, 0.0,0.0,0.0, &h00FFFFFF, 1.0,1.0), _
                                  (-5.0,  0.0, 5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,0.0), _
                                  ( 5.0,  0.0, 5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,1.0), _
                                  ( 5.0, 20.0, 5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,0.0), _
                                  (-5.0, 20.0, 5.0, 0.0,0.0,0.0, &h00FFFFFF, 0.0,1.0)}

DIM indices(0 to 35) as ushort = {0,1,2, 2,3,0, 4,5,6, _
                                  6,7,4, 0,3,5, 5,4,0, _
                                  3,2,6, 6,5,3, 2,1,7, _
                                  7,6,2, 1,0,4, 4,7,1 }

' -----------------------------------------------------------------------------
' create the mesh from the array of vertices and indices
MeshCentre = IrrCreateMesh( "MeshCentre", 8, vertsCentre(0), 36, indices(0))
MeshOffset = IrrCreateMesh( "MeshOffset", 8, vertsOffset(0), 36, indices(0))

' load texture resource for texturing the nodes
MeshTexture = IrrGetTexture( "./media/texture.jpg" )

' add two a chains of nodes
for i = 0 to 7
    LeftNodes(i)  = IrrAddMeshToScene( MeshCentre )
    IrrSetNodeMaterialTexture( LeftNodes(i), MeshTexture, 0 )
    if i > 0 then
        IrrSetNodeParent( LeftNodes(i), LastLeftNode )
        IrrSetNodePosition( LeftNodes(i), 0.0, 20.0, 0.0 )
    else
        IrrSetNodePosition( LeftNodes(i), -20.0, 0.0, 0.0 )
    end if

    RightNodes(i)  = IrrAddMeshToScene( MeshOffset )
    IrrSetNodeMaterialTexture( RightNodes(i), MeshTexture, 0 )
    if i > 0 then
        IrrSetNodeParent( RightNodes(i), LastRightNode )
        IrrSetNodePosition( RightNodes(i), 0.0, 20.0, 0.0 )
    else
        IrrSetNodePosition( RightNodes(i), 20.0, 0.0, 0.0 )
    end if

    LastLeftNode = LeftNodes(i)
    LastRightNode = RightNodes(i)
next i
    
' add a bright ambient light to the scene to brighten everything up
IrrSetAmbientLight( 1,1,1 )

' add a camera into the scene and resposition it to look at the pyramid
OurCamera = IrrAddFPSCamera
IrrSetNodePosition( OurCamera, 30,50,-125)
IrrSetCameraTarget(OurCamera, 0,75,0)
IrrHideMouse


' -----------------------------------------------------------------------------
' while the irrlicht environment is still running
WHILE IrrRunning
    ' begin the scene, erasing the canvas with sky-blue before rendering
    IrrBeginScene( 240, 255, 255 )

    ' animate the scene
    CubeRotation = cos(timer) * 10
    for i = 0 to 7
        IrrSetNodeRotation( LeftNodes(i),  0.0, 0.0, CubeRotation )
        IrrSetNodeRotation( RightNodes(i), 0.0, 0.0, CubeRotation )
    next i

    ' draw the scene
    IrrDrawScene
    
    ' end drawing the scene and render it
    IrrEndScene
WEND

' -----------------------------------------------------------------------------
' Stop the irrlicht engine and release resources
IrrStop

[super_castle]

I want to shift the center can evaluate using different.
I do not convert themselves.
I want it by a command.
estelle a cube with the Iberic peninsular and move later this zenrtum.

gruss

[agamemnus]

I want to shift the center can evaluate using different.
I do not convert themselves.
I want it by a command.
estelle a cube with the Iberic peninsular and move later this zenrtum.

gruss

*Picard facepalm*

Again, I am asking you to write in English that we can understand or ask someone to translate.

[agamemnus]

Frank Dodd:

I was able to fix my lighting problems. There were a few issues.

1.) Firstly (and this is a biggie), when a node is scaled, the normals must be changed accordingly. The normals are perpendicular rays (to the mesh) that define how light hits a mesh. To do this manually, I did:
"irrSetNodeMaterialFlag (node3d, IRR_EMF_normalize_normals, IRR_On)"

However, I see a usefulness in adding "node->setMaterialFlag(EMF_NORMALIZE_NORMALS, true);" to "IrrSetNodeScale" (perhaps at the beginning? I think it's just a flag, not a function that actually normalizes them?), since every time the node is scaled (if lighting is on for that model) the normals should be scaled too and it won't happen unless the normals are normalized. Perhaps this could be an option. I don't know.

2) I found that directX and openGL treated light intensity differently.

3) I found I needed a directional light for my uses, and I needed to rotate it 180 degrees in the Y direction.

4) I needed to set "IrrSetNodeColorByVertex (node3d, ECM_DIFFUSE_AND_AMBIENT)" (this is a new DLL function I made that simply colors ALL the materials in a node's mesh within a loop)

------------

I'm not quite ready to release my new proposed functions for the wrapper yet. I have collected quite a few of them. I am still evaluating whether they are useful to have in the wrapper.

I am also working on a new "library"-- a CEGUI wrapper as an add-on to the Irrlicht wrapper. I have some basic things done already and only one (macro?) line needs to be added to the Irrlicht wrapper's event function to make it compatible. (besides the definition [.def] file)

[Frank Dodd]

1.) Firstly (and this is a biggie), when a node is scaled, the normals must be changed accordingly. The normals are perpendicular rays (to the mesh) that define how light hits a mesh. To do this manually, I did:
"irrSetNodeMaterialFlag (node3d, IRR_EMF_normalize_normals, IRR_On)"

However, I see a usefulness in adding "node->setMaterialFlag(EMF_NORMALIZE_NORMALS, true);" to "IrrSetNodeScale" (perhaps at the beginning?

Thank you very much for discovering and pointing this out Agamemnus, this is a serious issue that I had not realised was there. I think your right that some re-normalising option has to be included.

I traced through the Irrlicht code and the function that is ultimatly called for the EMF_NORMALIZE_NORMALS flag is glEnable(GL_NORMALIZE) I have done some reading on it this morning, this discussion at Gamedev.net is interesting as is the OpenGL FAQ section 18.090, they both suggest that enabling it can effect performance. An alternative is to manually scale the normals on the mesh to compensate for the distortion just once (instead of every frame like GL_NORMALIZE) but I can see if scaling is called many times rounding errors are going to very quickly distort the normals on the mesh and rescaling normals on the mesh will effect all nodes (some of which could be scaled to different sizes).

This is tricky, I think some options are needed here where people can either do it automatically with IRR_EMF_NORMALIZE_NORMALS, do it manually with a normalizing function e.g: IrrSetMeshScale() but perhaps the most helpful thing that could be done is a good document on Lighting for the documentation folder (I have been thinking about this for a while along with ones on Collision and Scene Node Management).

I need a think about this, thanks very much for raising it as a problem.

2) I found that directX and openGL treated light intensity differently.

This is very possible they are two totally separate driver modules in Irrlicht that try to do the same job. It is possible some DX/GL specific code would be required in an application.

3) I found I needed a directional light for my uses, and I needed to rotate it 180 degrees in the Y direction.

Thanks again, I will take a look and see if the directional light is set up the wrong way around.

I'm not quite ready to release my new proposed functions for the wrapper yet. I have collected quite a few of them. I am still evaluating whether they are useful to have in the wrapper.

Certainly the wrapper should concentrate on functions that are generic or include important common features and that are not too specific to a particular application. But it would be nice too see all functions that you want to release, some one else could reuse them or base their own function on them later even if they aren't released into the wrapper.

I am also working on a new "library"-- a CEGUI wrapper as an add-on to the Irrlicht wrapper.

This sounds great and would certainly be supported. The Irrlicht GUI functions I have included are still very basic.

[super_castle]

Create a cuboid with the turning point in the center.
later, the turning point from the center shift for an arm movement.

gruss

[siskinedge]

I'm trying to move the wrapper to useing your 0.7.4 release but for some reason two problems happen when I try to migrate from useing 0.6.2:
1) it provides the mesh data correctly for all of the meshes except for one of the maps I have, symtoms of bug are:
the mesh loads fine graphically
the newton mesh generated from it dosen't work
it only applies to the shipcorridor01 mesh
2) I cant change the camera angle with IrrSetNodeRotation though this is kinda minor at the moment

[agamemnus]

Create a cuboid with the turning point in the center.
later, the turning point from the center shift for an arm movement.

gruss

Like Frank Dodd said, all you need is some math. Use irrSetNodeRotation to rotate the arm. If it's not rotating around the turning point, position the vertices such that the edge of the arm geometry is at the model origin point.

they both suggest that enabling it can effect performance. An alternative is to manually scale the normals on the mesh to compensate for the distortion just once (instead of every frame like GL_NORMALIZE) but I can see if scaling is called many times rounding errors are going to very quickly distort the normals on the mesh and rescaling normals on the mesh will effect all nodes (some of which could be scaled to different sizes).

I read those, but they aren't definitive. I would be very surprised if they really do get rescaled every frame.

This is tricky, I think some options are needed here where people can either do it automatically with IRR_EMF_NORMALIZE_NORMALS, do it manually with a normalizing function e.g: IrrSetMeshScale() but perhaps the most helpful thing that could be done is a good document on Lighting for the documentation folder (I have been thinking about this for a while along with ones on Collision and Scene Node Management).

Yeah, a manual normalizing function would be good. I doubt the scaling imprecision would be too much of a problem. It can be solved programatically -- if you expect to scale a lot, just keep the unscaled mesh in reserve and re-copy and scale from that. A document or some comments specifying how it all works in Irrlicht would be great. I can help you with it, if you'd like.


I'll post all the functions I have soon-ish then..

[Frank Dodd]

Hello Siskinedge
Its nice to hear from you I hope your project is progressing well. The big change for meshes that went into 0.7.4 was better support for Render Buffers. Every mesh can be composed of many groups of verticies and indicies and in 0.6.2 only the first buffer was processed, 0.7.4 allows access to each of the buffers, I changed ConvIrrmesh2Newton to iterate through the buffers especially as maps and BSPs often contain lots of render buffers. I really should also have updated ConvIrr2ConvHull but objects are far less likely to contain many buffers.

So the first thing I would look at is making sure all of the render buffers are processed "IrrlichtNewton.bi" in 0.7.4 is a good example. However I was comparing version 0.7.3 to 0.7.4 with WinMerge to see the problems I had to address in IrrlichtNewton.bi and I can see that in NewtonSizeWorld I had also changed: -

Code: Select all

    boxP0(0) -= 100.0
    boxP0(1) -= 100.0
    boxP0(2) -= 100.0
    boxP1(0) += 100.0
    boxP1(1) += 100.0
    boxP1(2) += 100.0

... to... 

    boxP0(0) -= 100.0
    boxP0(1) -= 00.0
    boxP0(2) -= 100.0
    boxP1(0) += 100.0
    boxP1(1) += 500.0
    boxP1(2) += 100.0

This was a temporary fix I included to set the world size and allow the physics to run. I forgot to place this on my to do list and thought it was working in general so there may be a problem with the world size and an issue with the calls to NewtonBodyGetMatrix and NewtonCollisionCalculateAABB. Its on my todo list now but may be a while before I can look into it.

I will take a peep at camera rotations, I believe I used them myself recently though.

I noticed that you initially did some work with ODE rather than Newton, I am interested to know why you changed to Newton. ODE looked very interesting to me because of the more liberal licensing terms.


Hello Agamemnus
The scaling imprecision wouldn't be a problem for dozens of calls but it would creep in slowly, I have seen a similar problem when working on the 6DOF camera, that accumulated rotations and after a while the rounding errors began to skew the model.

I think you have made an excellent suggestion about copying from a template mesh to correct rounding errors. This could in fact be a part of the command so if you supplied an optional source mesh the verticies would be read from that scaled and copied into the destination, otherwise they would be read from and written to the destination mesh. This sounds like the solution.

Any help is always appreciated even if its just a small function, a couple of paragraphs or some help with a question.

Hello Super Castle
I think you will find this solution much better. Its far more straightforward and personally the more simple the solution is the more I like it (as long as its still fast and this is) :D

Code: Select all

'' ----------------------------------------------------------------------------
'' Rotate around a pivot node
'' ----------------------------------------------------------------------------

'' ////////////////////////////////////////////////////////////////////////////
'' Includes for extension libraries
#include "IrrlichtWrapper.bi"

'' ////////////////////////////////////////////////////////////////////////////
'' global variables

' irrlicht objects
Dim Mesh As irr_mesh
Dim MeshTexture As irr_texture
Dim OurCamera As irr_camera
Dim CentreNode As irr_node
Dim EdgeNode As irr_node
Dim PivotNode As irr_node
Dim CubeRotation As Double

'' ////////////////////////////////////////////////////////////////////////////
'' GDB debugger main() function

' -----------------------------------------------------------------------------
' start the irrlicht interface
IrrStart( IRR_EDT_OPENGL, 512, 512, IRR_BITS_PER_PIXEL_32, _
        IRR_WINDOWED, IRR_NO_SHADOWS, IRR_IGNORE_EVENTS )

' set the window caption
IrrSetWindowCaption( "Rotate around a point" )

' load a texture 
MeshTexture = IrrGetTexture( "./media/texture.jpg" )

' create a long box and move it to the side
CentreNode = IrrAddTestSceneNode
IrrSetNodeMaterialTexture( CentreNode, MeshTexture, 0 )
IrrSetNodeScale( CentreNode, 1.0, 3.0, 1.0 )
IrrSetNodePosition( CentreNode, -15.0, 0.0, 0.0 )

' create a pivot node, this node is invisible and represents the center of
' rotation on any nodes that are attached to it. move it to the side. to move
' the objects around we move THIS node
PivotNode = IrrAddEmptySceneNode
IrrSetNodePosition( PivotNode, 15.0, 0.0, 0.0 )

' create another long box
EdgeNode = IrrAddTestSceneNode
IrrSetNodeMaterialTexture( EdgeNode, MeshTexture, 0 )
IrrSetNodeScale( EdgeNode, 1.0, 3.0, 1.0 )

' attach the box to the pivot point, move it up so the pivot point is resting on
' its edge. to move the center of rotation we move THIS node
IrrSetNodeParent( EdgeNode, PivotNode )
IrrSetNodePosition( EdgeNode, 0.0, 15.0, 0.0 )

' add a bright ambient light to the scene to brighten everything up
IrrSetAmbientLight( 1,1,1 )

' add a camera into the scene and resposition it
OurCamera = IrrAddCamera( 0,0,100, 0,0,0 )
IrrHideMouse


' -----------------------------------------------------------------------------
' while the irrlicht environment is still running
While IrrRunning
    ' begin the scene, erasing the canvas with sky-blue before rendering
    IrrBeginScene( 0, 0, 0 )

    ' animate the scene rotating the first cube and the PIVOT object
    CubeRotation = Timer * 100
    IrrSetNodeRotation( CentreNode, 0.0, 0.0, CubeRotation )
    IrrSetNodeRotation( PivotNode, 0.0, 0.0, CubeRotation )
    
    ' draw the scene
    IrrDrawScene
   
    ' end drawing the scene and render it
    IrrEndScene
Wend

' -----------------------------------------------------------------------------
' Stop the irrlicht engine and release resources
IrrStop

[siskinedge]

kewl I'll update my code to include your multi buffer support, in the next release I've got some intresting stuff planned:
more data access functions - done
physics enabled particle effects - done
file loadable special effects - WIP
SFX and particle 'aliases' (use them by name, loaded from a file) - mostly done
loadable user defined SFX callbacks (with defualt ones) - mostly done
useing zones for a LOD manager (just on and off for now) - working on now

[super_castle]

Very good.
This solution can I find nice for me as a beginner.

Gruss

[siskinedge]

as a side note I started doing newton, found it too hard switched to ODE made some good progress but then I went back to newton with what I learnt from ODE. I switched cos Newton is more precise and from what I have been doing with it, easier to use. I might at some point once I have got the physics features set I would call 'satisfactory' intergrate ODE with what I have learnt from Newton into the wrapper so that it's like:
use ODEstart or NewtonStart
with all the same commands for simplicity

I also think newton is more activity developed, has better colision and they are working on a GPU accelerated solver. with those factors it could be quite posible to use this kinda wrapper for full on game development. besides as far as I can tell from the newton license it's like:
free to use as long as you say they made it and tell them when you use it.

that reminds me, I should totally post the wrapper on the newton forumn on the next release. mabey make a youtube video too, cos like explosions and stuff.

[siskinedge]

I've done some more testing and the problem is my own code, though it's 'solution' brings up this weird older bug it has that has been observed from now 7 different causes. I've also made the correct adaptions to allow multiple buffers for convex hull objects. here is the code for that:

Code: Select all

Sub ConvIrr2ConvHull( Byref targetmesh As irr_mesh, Byref ConvertedColision As NewtonCollision Ptr )
    'Define Variables
    Dim MeshBufferTotal As Integer									'Total Mesh Buffers
    Dim MeshBufferLoop As Integer									'Current Buffer
    Dim MeshVertextotal As UInteger									'Total Vertexs
    Dim MeshVertexLoop As Integer									'Current Vertex overall
    Dim TempLoop As Integer											'Loop Variable
    Dim VertTotal As Integer											'Total Vertexes
    
    'Get Mesh Vertex total
    MeshBufferTotal = IrrGetMeshBufferCount( targetmesh, 0 )
    Dim BufferVertexTotal(MeshBufferTotal-1) As Integer		'Store all the buffer totals to save repeative code
    VertTotal = -1
    For MeshBufferLoop = 0 To MeshBufferTotal-1
    	'First get count in this buffer
    	BufferVertexTotal(MeshBufferLoop) = IrrGetMeshVertexCount(targetmesh, 0, MeshBufferLoop )
    	'Then add this to the total amount of vertexes
    	VertTotal = VertTotal + BufferVertexTotal(MeshBufferLoop)    	
    Next
        
    'Next we need to define the end Vertex Pool
    Dim ConvNewtVertexB(VertTotal) As dFloatVector
    
    'Now We add the vertex data to this defined pool
    MeshVertexLoop = 0
    For MeshBufferLoop = 0 To MeshBufferTotal-1
    	'Declare Vertex buffer
    	Dim ConvNewtVertex(BufferVertexTotal(MeshBufferLoop)-1) As IRR_VERT
    	'Get irrlicht vertices from this buffer
    	IrrGetMeshVertices(targetmesh,0,ConvNewtVertex(0), MeshBufferLoop )
    	'Stuff vertices into end buffer
    	For Temploop = 0 To BufferVertexTotal(MeshBufferLoop)-1
    		' convert a single vertex
        	ConvNewtVertexB(MeshVertexLoop).x=ConvNewtVertex(Temploop).x
        	ConvNewtVertexB(MeshVertexLoop).y=ConvNewtVertex(Temploop).y
        	ConvNewtVertexB(MeshVertexLoop).z=ConvNewtVertex(Temploop).z
        	' Increment the vertex being worked on
        	MeshVertexLoop = MeshVertexLoop + 1
    	Next
    Next
    
    'Commit this buffer to the Collision
    ConvertedColision=NewtonCreateConvexHull(nWorld, VertTotal, @ConvNewtVertexB(0).x, 12, 0 )
End Sub

[The Car]

Frank,

I have added the following function so I could draw a 2d image with a destination size different from the source:

bi:

Code: Select all

declare sub IrrDraw2DImageElementStretch CDECL alias "IrrDraw2DImageElementStretch" ( byval texture as irr_texture, byval dest_tx as integer, byval dest_ty as integer, byval dest_bx as integer, byval dest_by as Integer, byval source_tx as integer, byval source_ty as integer, byval source_bx as integer, byval source_by as integer, byval usealpha as integer )

wrapper2d.cpp:

Code: Select all

void DLL_EXPORT IrrDraw2DImageElementStretch(
                                video::ITexture *texture,
                                int dTX, int dTY, int dBX, int dBY,
                                int TX, int TY, int BX, int BY,
                                bool usealpha )
{		
    driver->draw2DImage(
            texture,
            rect<s32>(dTX,dTY,dBX,dBY),
            rect<s32>(TX,TY,BX,BY),
            NULL,
            NULL,
            usealpha
    );
}

Eric Carr

[siskinedge]

I think the problem isn't the size of the newton world itself but to do with the updateing. I've fixed this by handing off timer update handleing more unto the wrapper, though I am working on a time dialation setting so it's posible to scale time. scene homogenously scaled time though, none of that locally scaled time distortion crap.