Irr1.8c++| How can i project a useable grid on to my Terrain

[Ultraporing]

Could be the number of primitives should be 1 (I think that's the 4th parameter). I mean it's just one LINE_STRIP per loop with the length of widthInCells/heightInCells, right? Though I'm not certain why it works at all then or how it interprets any number > 1 for line_strips. Should probably try to draw widthInCells times a line_strip of widthInCells length, but why it doesn't crash if tje vertex given only contains 1 ... not sure. If you used a single array instead you probably wouldn't even need a loop there, but could do something like:

Code: Select all

 
driver->drawVertexPrimitiveList(&verticesVertical[0], widthInCells, &uIndicesVertical[0], heightInCells, EVT_STANDARD, EPT_LINE_STRIP);
 

Not working in your case as your memory is not continuos. But if it where this would draw heightInCells times a linestrip with widthInCells vertices.

I have to set the primitives to widthincells because when i set it to 1 i only draw from point 1 to point 2.
The problem is when I use a single array the lines are all over the place because i have to draw every line seperatly to create the grid. When i have everything in one array this dont work.
But i can be wrong about it, the way i tried it it didnt work.

just tried it again with one array the way you mentioned it. And the lines flew all over the place^^


My current source of the class (formatting screwed up by pastebin >.<):

EDE_GridSceneNode.h: http://pastebin.com/xJCBYh2x
EDE_GridSceneNode.cpp: http://pastebin.com/euXMvipx

[CuteAlien]

That's suspicious - why would it only draw from point 1 to 2 when you give it a higher vertex count? Just to be sure we are talking about the same - the second parameter should still be withInCells and the 4th parameter should be 1. And that does only draw a single line and not a line-strip?

Sorry, I'm pretty confused by this - but I've not worked with line-strips, maybe I'm missing something...

I just took a look at your position calcluations. There's a few things there - but maybe you probably shouldn't use getAbsolutePosition there at all. Instead calculated with positions around your node-origin (whereever you set that - 0,0,0 for example). And then before rendering set the driver to the absolute transformation matrix of the node which will move everything to the absolute position. It's the same result - but way easier to follow the calculations and will then also allow stuff like rotating and scaling the node.

[Ultraporing]

That's suspicious - why would it only draw from point 1 to 2 when you give it a higher vertex count? Just to be sure we are talking about the same - the second parameter should still be withInCells and the 4th parameter should be 1. And that does only draw a single line and not a line-strip?

Sorry, I'm pretty confused by this - but I've not worked with line-strips, maybe I'm missing something...

I just took a look at your position calcluations. There's a few things there - but maybe you probably shouldn't use getAbsolutePosition there at all. Instead calculated with positions around your node-origin (whereever you set that - 0,0,0 for example). And then before rendering set the driver to the absolute transformation matrix of the node which will move everything to the absolute position. It's the same result - but way easier to follow the calculations and will then also allow stuff like rotating and scaling the node.

with the last sentences you confused me^^, no idea how to do that.
To the first regarding the strips, when i set the 4th parameter to 1 i only draw a single line with the size of cellSize and it moves then to the next strip. I'll make a screenshot

Here is a screen of it with 4th param = 1:

[CuteAlien]

Some more things ... shoudn't drawVertexPrimitiveList use +1 in the second parameter? Otherwise you seem to ignore the last vertex in each line. Maybe use a variable anyway for those width+1 and height+1 calculations everywhere that makes it more clear what you are working there with.

And while I don't know what's wrong with the single-array (maybe line-strips not working as I expect?), when you are using multiple arrays you probably would only need a single indices array for each line as those are all filled by the same values. Just a tiny optimization - not your bug.

Also about the grid vanishing when it's too small... could this line be the reason?

Code: Select all

        this->widthInCells = (int)((heightmapTexture->getSize().Width  - 8) / cellSize);
[code]

18-8 is 10. Divided by some cellSize... what exactly is the value you have in widthInCells after that? Maybe there's no grid left.

[Ultraporing]

It dont vanishes the last 2 lines bug around and are pulled away to a single point outside of the terrain or the grid, I made a screenshot of it.
 
Sorry didnt gave you the parameters:

Code: Select all

 
EDE_GridSceneNode* gridS = new EDE_GridSceneNode(scnNode, scnMgr);
gridS->initGridOverPositionTerrain(scnNode, 20, 25, vector3df(25.0f, 0.0f, 10.0f));
 

Cell size is by default 1

[CuteAlien]

Hm, before I dig deeper please tell me which driver&OS you are using right now (opengl/directX, linux/windows) as behaviour for line-strips might not be the same everywhere.

[Ultraporing]

Hm, before I dig deeper please tell me which driver&OS you are using right now (opengl/directX, linux/windows) as behaviour for line-strips might not be the same everywhere.

Windows 7 x64, DirectX

[CuteAlien]

Sorry, things getting confusing and I'm certainly just on the wrong system at the moment (linux+opengl). I don't understand the Microsoft documentation for the line_strip parameter. Either it's not possible to draw several line-strips at once (could be) then primitives might in this case not mean primitives but describe how many indices to use. Or it is possible - then the calculation for the strip-length is simply not described and could be something like vertices/primitives maybe. Really can't tell without writing some tests first myself and unfortunately I won't find time for this :-(

But some other stuff at least...

What I said about getAbsolutePosition. If you write your own SceneNodes then the node itself should not have to care about it's absolute position. That is what makes it so powerful - it only has some center around which it places it's vertices. And then it can be used in any place with rotation and scaling and moved around or have any matrix transformation because the points are transformed before the drawing. It also makes calculations easier - you no longer have to think about adding those transformations to every calculation constantly. So in render you don't call driver->setTransform(ETS_WORLD,matrix4()) but instead you call driver->setTransform(ETS_WORLD, AbsoluteTransformation) and it will ensure all those node-transformation are added before drawing.

Why this matter... think about that calculation (it's part of calculation the X coordinate of your vertices):

Code: Select all

 
(terrainSceneNode->getAbsolutePosition().X * (x+1))
 

What this does is that it scales your grid's x-coordinates by the position of the scenenode (meaning if you would move your grid to the right it will suddenly get larger). I'm pretty certain that is not what you wanted and only seems to work because it's most likely 0 anyway at the moment and so that part adds just 0 to the result :-) Just get rid of it and calculations will look way easier.

That said - I think there was a recently a bugreport about the terrainscenenode that it's also not doing that (being independent of absolute positions) for reasons which we still have to figure out ourselves *sigh*: http://irrlicht.sourceforge.net/forum/v ... =7&t=48051
But that mainly means that getAbsolutePosition() does not work correct for terrainscenenodes right now (getPosition() works I think), so just another reason not to use it here.

Sorry, can't be of much more help today.

[Ultraporing]

Thank you for the Tip and I understand you dont have time to answer all questions .

But after using the driver->setTransform(ETS_WORLD, AbsoluteTransformation); my height (Y) dont work anymore of the vertices, it creates a flat grid with the size i defined. Did I miss something again?

[CuteAlien]

Does getHeight (which you use to find y of vertices) suddenly return 0? Another explanation would be if you have used setScale on the node (or a parent) with y == 0.

[Ultraporing]

Does getHeight (which you use to find y of vertices) suddenly return 0? Another explanation would be if you have used setScale on the node (or a parent) with y == 0.

I had the Y scale on 0.1f because my terrain was spikes with 1f. With 1f its working again Oo but my terrain now consists of spikes .

Nvm I used a better heightmap now all is ok .

[CuteAlien]

Or use setScale on your gridnow now with y=10 or so. That should work now.

[Ultraporing]

#UPDATE!!: I tested OpenGL and the grid bugs only in DirectX 9 mode. In OpenGL It dont does weired stuff!

hm my grid still goes full retard when I create it with a smaller size than 18.


Here are 2 screens with size 16 from 2 diffrent angles:




Current Code:

EDE_GridSceneNode.cpp
http://pastebin.com/TPaDyH9n

EDE_GridSceneNode.h
http://pastebin.com/LHigKUPn

Useage:

Code: Select all

 
ITerrainSceneNode* scnNode = scnMgr->addTerrainSceneNode(
        "151009heightmapsr_bed.png",
        scnMgr->getRootSceneNode(),
        -1,                 // node id
        core::vector3df(0.f, 0.f, 0.f),     // position
        core::vector3df(0.f, 0.f, 0.f),     // rotation
        core::vector3df(1.0f, 1.0f, 1.0f),  // scale
        video::SColor ( 255, 255, 255, 255 ),   // vertexColor
        4,                  // maxLOD
        ETPS_9,             // patchSize
        3                   // smoothFactor
        );
 
    scnNode->setMaterialFlag(video::EMF_LIGHTING, false);
    scnNode->setMaterialTexture(0, videoDrv->getTexture("free-grass-texture-013.jpg"));
    scnNode->scaleTexture(5.0f);
    ITexture *tex = videoDrv->getTexture("151009heightmapsr_bed.png");
    
    EDE_GridSceneNode* gridS = new EDE_GridSceneNode(scnNode, scnMgr);
    gridS->initGridOverPositionTerrain(scnNode, 16, 16, vector3df(24.0f, 0.0f, 6.0f));