New Tiled Terrain Scene Node [works with Irr 1.5]

mjp5060 · Post by **mjp5060** » Sat May 30, 2009 5:20 am

got ya, thanks for the info.

egrath · Post by **egrath** » Thu Jun 18, 2009 10:53 am

Hello,
in File ShTlTerrainSceneNode.cpp on line 194:

CTexture = driver->addTexture(core::dimension2d<s32>(tw, th), "colortexture", video::ECF_A8R8G8B8);

has to be replaced with:

Code: Select all

CTexture = driver->addTexture(core::dimension2d<u32>(tw, th), "colortexture", video::ECF_A8R8G8B8);

(u32 instead of s32)
to make it compile without errors on 1.5

Thanks for creating this wonderful Terrain Scene Node!

Egon

hybrid · Post by **hybrid** » Thu Jun 18, 2009 12:11 pm

This change is only necessary for compilation under 1.6 (SVN/trunk), because 1.5 still uses the old s32 interface.

digoxy · Post by **digoxy** » Sun Mar 07, 2010 8:39 am

(I originally posted this in the thread "Code Snippits")

Hello Gang,

using irrLicht 1.7.1, Visual C 08.

arras, I gotta admit, your SomeFunctions.h had to be ported from somwhere, possibly another application of yours! I get beat up by this booger so much! LOL!

This class is kicking my rearend, I know these are just warnings but I would like to clear them to prevent any other issues.

Code: Select all

void makeRandomHills(ShTlTerrainSceneNode* node, s32 hillCount, s32 maxRadius)
{
   double pi = 3.1415926535;

   // make hills
   for(int n=0; n<hillCount; n++)
   {
      s32 radius = rnd(1, maxRadius);
      f32 height = rnd(1, radius);
      height = height/10;
      core::vector2d<s32> pos;
      pos.X = rnd(-radius, node->getSize().Width-radius);
      pos.Y = rnd(-radius, node->getSize().Height-radius);

      // decide if add or substract
      if(rnd(1)==1) height = -height;

      // create hill using sinus and distance to center
      for(int j=0; j<=radius*2; j++)
         for(int i=0; i<=radius*2; i++)
         {
            f32 distance = core::vector2d<s32>(i-radius, j-radius).getLength();
            if(distance <= radius)
            {
               f32 v = radius;
               v = v - distance;
               v = v / radius;
               v = v * pi / 2;
               v = sin(v);
               if(pos.X+i>=0 && pos.X+i<node->getSize().Width+1 && pos.Y+j>=0 && pos.Y+j<node->getSize().Height+1)
                  node->setHeight(pos.X+i, pos.Y+j, node->getHeight(pos.X+i, pos.Y+j)+v*height*node->getTileSize());
            }
         }
   }
}

Neat operation no doubt but with some vars that dont like each other or something, it may also be the conventions in irrlicht that are being kicked back, however, the case is this when I compile to debug/

Code: Select all


1>c:\users\valued customer\documents\visual studio 2008\projects\shtit2\somefunctions.h(19) : warning C4244: 'initializing' : conversion from 'int' to 'irr::f32', possible loss of data
1>c:\users\valued customer\documents\visual studio 2008\projects\shtit2\somefunctions.h(32) : warning C4244: 'initializing' : conversion from 'irr::s32' to 'irr::f32', possible loss of data
1>c:\users\valued customer\documents\visual studio 2008\projects\shtit2\somefunctions.h(35) : warning C4244: 'initializing' : conversion from 'irr::s32' to 'irr::f32', possible loss of data
1>c:\users\valued customer\documents\visual studio 2008\projects\shtit2\somefunctions.h(38) : warning C4244: '=' : conversion from 'double' to 'irr::f32', possible loss of data
1>ShTlTerrainSceneNode.cpp
1>c:\users\valued customer\documents\visual studio 2008\projects\shtit2\shtlterrainscenenode.cpp(1235) : warning C4018: '<' : signed/unsigned mismatch
1>c:\users\valued customer\documents\visual studio 2008\projects\shtit2\shtlterrainscenenode.cpp(1237) : warning C4018: '<' : signed/unsigned mismatch

I can only assume that the other two warnings in shtlterrainscenenode.cpp may clear up after these above are fixed.

I will also add, the demo runs fine, really fine!

Any feedback on this would be greatly appreciated.

@Arras<-thank you for an awesome pager!

shadowslair · Post by **shadowslair** » Sun Mar 07, 2010 10:42 am

Lol, brother I see you`re as pedantic as I am, but these are really, really easy to fix. Looks like you don`t make any difference between these types. Here`s a short explanation:

s32 - signed int, which means it is a whole number and can be postive or negative ( +/- )
u32 - the same int as the one above, except it is always >=0 (no minus sign). If you pass a negative value to it you`ll get some unwilling behaviour.

When you compare these it`s nice to compare variables of the same type like (s32 a <!=> s32 b) having (u32 a<!=> s32 b) will show you the same warning.

If you cannot simply change it yourself like it`s passed from an Irrlicht function you can always try some convertion like float(int a) < float b.

If you create a variable like f32 myFloatVar and assign a value to it like myFloatVar = 1.4; then you better add an "f" suffix to the value so the compiler will know you`re assigning a "float" value to the "float var". Like f32 myFloatVar = 1.4f;

And on...

digoxy · Post by **digoxy** » Sun Mar 07, 2010 2:05 pm

shadowslair, Thank you for your response. I am eager to learn there is no question about that!

I have only in the last week wrapped my head around using the types in conjunction with regular C++ types, drawing the right irrlicht type for a script takes me to the conversion chart everytime! LOL!

Learning to troubleshoot the type declerations in the workflow is where I am now and this was a great example of how to fix not only these issues but also several others.

I would like to have his script function without a warning, what would you do to clean this up? Take the first one here:

Code: Select all

 f32 height = rnd(1, radius);

should this be something like f32 height = f32 rnd(1, radius); ?

The reason we see this warning is because the vars are not of the same type (as far as VC is concerned)? Does this compile on say linux without a warning?

Strange things really.. for me that is!

Code: Select all

  if(MeshSize.Width < CTexture->getSize().Width) w = 1;
    s32 h = 0;
    if(MeshSize.Height < CTexture->getSize().Height) h = 1;

This one what would we do here?

Maybe this should be moved to beginner or something! This is prolly really basic Irrlicht stuff.

shadowslair · Post by **shadowslair** » Sun Mar 07, 2010 5:06 pm

Too lazy to browse the code or to set up a project for that, but here`s a quick guess:

f32 height = rnd(1, radius); should be sth like: f32 height = f32 (rnd(1, radius)); or f32 height = (f32) rnd(1, radius);

The other one is because MeshSize is a s32 2d dimension, where texture size is u32. It should be sth like:

if(MeshSize.Width < s32(CTexture->getSize().Width)) w = 1;
s32 h = 0;
if(MeshSize.Height < s32(CTexture->getSize().Height)) h = 1;

It`s not Irrlicht stuff, it`s a basic C++ or programming conversion stuff...

digoxy · Post by **digoxy** » Mon Mar 08, 2010 10:55 am

I used both of your examples and this cleared the two you mentioned here! Thank you.

arras · Post by **arras** » Mon Mar 08, 2010 3:14 pm

Hi digoxy,

I was coding it in DevC++ witch is for some reason quit happy with assigning different types to each other. I did switch to CodeBlocks since but newer did run those functions trough it (its function not class).

Basically you need to use "casting" to tell compiler you really want to assign value to variable of different kind. It will "turn off" all compiler safeguarding, so you should understand what are you doing.

shadowslair did wrote some basics but you make casting by using brackets. For example, if you want to assign int value to float variable:

Code: Select all

int i = 10;
float f = (float)i;

This is pretty safe operation as there is no danger of loosing part of data as you can store whole int in to float (remember everything is represented by 0 and 1 on ground level).

Other way around is more dangerous:

Code: Select all

float f = 10.9f;
int i  = (int)f;

In this case everything after decimal point will be discarded. You should understand that prior doing it as compiler will not warn you if its not what you expect it to do.

Even more mistake prone can be to cast int into unsigned int.

That's of course not to discourage you from using casting. Casting is one of the more useful features of C++. Just be careful.

Here is function makeRandomHills which I run through Code Blocks:

Code: Select all

void makeRandomHills(ShTlTerrainSceneNode* node, s32 hillCount, s32 maxRadius)
{
   double pi = 3.1415926535;

   // make hills
   for(int n=0; n<hillCount; n++)
   {
      s32 radius = rnd(1, maxRadius);
      f32 height = (f32)rnd(1, radius);
      height = height/10;
      core::vector2d<s32> pos;
      pos.X = rnd(-radius, node->getSize().Width-radius);
      pos.Y = rnd(-radius, node->getSize().Height-radius);

      // decide if add or substract
      if(rnd(1)==1) height = -height;

      // create hill using sinus and distance to center
      for(s32 j=0; j<=radius*2; j++)
         for(s32 i=0; i<=radius*2; i++)
         {
            f32 distance = core::vector2d<s32>(i-radius, j-radius).getLength();
            if(distance <= radius)
            {
               f32 v = (f32)radius;
               v = v - distance;
               v = v / radius;
               v = v * pi / 2;
               v = sin(v);
               if(pos.X+i>=0 && pos.X+i<node->getSize().Width+1 && pos.Y+j>=0 && pos.Y+j<node->getSize().Height+1)
                  node->setHeight(pos.X+i, pos.Y+j, node->getHeight(pos.X+i, pos.Y+j)+v*height*node->getTileSize());
            }
         }
   }
}

Bye the way, when I posted this code for the first time, it was full of this kind of stuff

Dorth · Post by **Dorth** » Mon Mar 08, 2010 6:30 pm

Well, it's worth mentioning that every time you're using casting, it's a bit as if you were mixing different measures (pints, meters, hours) and you should be wary that what you end up with is indeed what you were looking for. You might want float / int like you might want kilometers / hours, just that converting everything blindly is a good way to miss a bug in happening.

digoxy · Post by **digoxy** » Mon Mar 08, 2010 10:01 pm

Thanks guys, I know in working in some of the other languages that I deal with (mostly scripting stuff) it is good practice to keep it clean. I do my best. As new as I am to irrlicht though and understanding the "casting" used its sometimes hard for me to follow. I do appreciate you guys spending the time in helping me understand.

@Arras, thanks for spending the time as you do with the folks here, I have read this entire thread a few times now. You are a very helpful individual and your patience is very credible. To spend the time to put something together so awesome as this and then to share it with the community and then assist so many in helping to get it integrated into their projects is absolutely incredible.

Thank you Arras.

I do know that there are definitely a couple of things that could be added just from reading, and, maybe, someday I might be able to contribute however, as it is now, I am working with what you have delivered.

-Will you ever add support for adding physics? (obtaining verts?)
-Do you plan to page an entire terrain to make it truly endless? (using files)
-Are you still updating this great addon?
-when a "tile" is removed while you navigate, is it also removed from memory?

I hope this isnt to much, I know I get wordy but try to get to the questions directly.

Thanks guys
digz..

EDIT: BTW, that lil update fixed another one, I only have two left!

May never clear these, but, I thought I would put them out there. BTW code blocks, does it report these warnings? or is this just a Microsoft thing?

Code: Select all

1>visual studio 2008\projects\letsgohuntin\somefunctions.h(32) : warning C4244: 'initializing' : conversion from 'irr::s32' to 'irr::f32', possible loss of data
1>visual studio 2008\projects\letsgohuntin\somefunctions.h(38) : warning C4244: '=' : conversion from 'double' to 'irr::f32', possible loss of data

Line 32 //  f32 distance = core::vector2d<s32>(i-radius, j-radius).getLength(); 

Line 38 // v = v * pi / 2;

Digz.

shadowslair · Post by **shadowslair** » Mon Mar 08, 2010 11:25 pm

Maybe:

Code: Select all

f32 distance = core::vector2d<f32>(i-radius, j-radius).getLength();
v = v *core::PI / 2; // too lazy to look at the code right now

Please keep posting in "Beginner`s help" since these umm... "problems" are not directly related to the project. I believe we`ll all be happy when you compile it without any warnings.

digoxy · Post by **digoxy** » Tue Mar 09, 2010 12:58 am

Yes, off to beginners I go. Thanks guys.

arras · Post by **arras** » Tue Mar 09, 2010 9:56 am

As your problems are directly related to my code, you can keep posting here. No problem on my side. At last I might clean those warnings myself and update sourcecode download at the first page. This is after all for anybody using any compiler, not just me and mine.

Each compiler is bit different and each can be also adjusted with settings. So one might throw warning at line other is completely happy with. Codeblocks will for example not warn you if you assign int to float. Probably since it is totally safe operation. It might be, you can change it somewhere in compiler settings but I newer cared. When compiler throws warning it does not mean you do something against C++ rules, just that you might do something unsafe. It's up to you if you will address it or not but in general its wise to to so.

When casting, you tell compiler to treat it as something else, something different from what you have declared it to be. Each type or object occupy certain space in memory and have certain structure of its "data". When casting, compiler will treat it as if it would have been of different size and structure. You better turn to C++ literature for more info. There is plenty info on internet too. I was learning C++ from this book among other things: Thinking in C++ 2nd Edition by Bruce Eckel. Its free and available in electronic format.

-Will you ever add support for adding physics? (obtaining verts?)

I don't know what you mean by that. You can get height of any tile corner given you know its coordinates (in tiles) with virtual f32 getHeight(s32 w, s32 h); and you can get its normal with virtual core::vector3df getNormal(s32 w, s32 h);. There are corresponding seter functions also so you can modifi (deform) terrain at run time. You can get any height of terrain at any coordinate with virtual f32 getHeight(core::vector3df pos); and last you can get intersection with line using virtual bool getIntersectionWithLine( core::line3d<f32> line, core::vector3df &outIntersection);. That pretty much covers all physical interaction with terrain needed I can imagine.
If you however mean integration with some physical engine out there (like Newton), than no, I don't plan on that but I might help you to do it. That might however include only advice, I will not have time for some heavy coding so you would be one to carry on burden. If it is something what might be useful to others as well I can integrate it to my code at the end (with proper credit of course). Perhaps function giving access directly to mesh or something like that.

-Do you plan to page an entire terrain to make it truly endless? (using files)

No I don't.

-Are you still updating this great addon?

No I don't. I was planing to develop it further with texture blending (current texturing method is not too flexible) and I was planing LOD of kind. I wanted to use "atlas" texture for blending but so far Irrlicht does not grant access to mipmap levels and without one atlas texture will not work good. hybrid did plan to implement direct access to mipmap levels in to Irrlicht but it is apparently not high on to-do list so no idea when and if at all it will be implemented.

I was also thinking to make it more "Irrlichtish" in stile by building it on interface classes like IMeshBuffer and IMesh. Basically following Irrlicht node structure more rigidly.

-when a "tile" is removed while you navigate, is it also removed from memory?

No, tiles are not removed from memory when mesh shifts in to new position. There is no reason as no new ones are added. Same set of tiles is used all the time. Instead whole mesh is moved and updated at the new position. This happens in void ShTlTerrainSceneNode::updateVertices(TlTSector &sector). Only time some tiles are added or removed is when you initiate terrain or resize its visible mesh.

EDIT: I just saw changelist for Irrlicht 1.7 and it seems, hybrid did implement access to texture mipmaps after all. I will look at it as soon as I download latest version (I am still using Irrlicht 1.5). Thanks hybrid!

digoxy · Post by **digoxy** » Tue Mar 09, 2010 12:53 pm

Here you are again Arras, you are wonderful in your explinations and time you so willingly provide.

Arras, anytime you want me to compile your code for testing or anything at all, just ask. I will surely assist you in any way I can, including but not limited to any tedious work you may need to do, assign me whatever you will, just PM me.

It might be, you can change it somewhere in compiler settings

Unfortuanatly I want to know everything, I wouldnt dream of turning this off, I bet shadowslair does the same! I like a clean house.

Thinking in C++ 2nd Edition by Bruce Eckel

I am on this site many times during my adventures in Irrlicht, its very useful and for anyone using C++ I would think it to be a "tool", This and the IrrLicht CHM work nicely together.

I was also thinking to make it more "Irrlichtish"

Arras, I dont think you can go wrong here. It seems as an addon for the big picture, this suggestion IMO would be something surely to consider. Reading through this thread and also knowing that the possibility to add this to the irrlicht library was being reviewed could not only help the irrlicht library but also many "many" 3d programmers using Irrlicht. By the response of your Tiled Terrain and also responses on the french forum as well to the subject it seems that there is a great interest in the Tiled Terrain applications in not only Irrlicht but many of the 3d engines.

Digoxy wrote:

-Will you ever add support for adding physics? (obtaining verts?)

arras wrote

I don't plan on that but I might help you to do it. That might however include only advice, I will not have time for some heavy coding so you would be one to carry on burden.

I am a bit away from actually contributing code to your project, however, I hope to one day be there, sooner than later I hope!

I will do what I can to mull over your Tiled Terrain, I have it integrated with a couple of play projects I have and do beat it up some!

In all, I think you have many of the general location devices in place for physics and until I actually get a physics engine in place working properly I am afraid I cant be any more specific or generate any new ideas in this area. I will certainly let you know how this goes and give you feedback if you like.

Digoxy wrote:

-Do you plan to page an entire terrain to make it truly endless? (using files)

arras wrote

No I don't.

just know that like myself, many people are looking for that "endless" terrain as presented in WOW. Your code is the beginning of that in the free community without having to spend a few months putting it together themselves.

arras wrote

planing to develop it further with texture blending

I see your edit and see that hybrid has come through, wonderful. I am so looking forward to this and hope you can find time to incorporate your new texture blending.

Digoxy wrote:

-when a "tile" is removed while you navigate, is it also removed from memory?

arras wrote

No, tiles are not removed from memory when mesh shifts in to new position.

Again, my thinking around truly endless terrain, shifting into a newly loaded terrain would need to have the old one removed to conserve memory. In theory, using files, we should be able to construct many terrains, load them, unload them etc. I know this is far reaching however, if indeed your in a rewrite, maybe you could consider some of these idea's.

If say you have three 1024 terrains complete with hightmaps, in a truly enless world, we should be able to place these terrains in locations. in the "grid" for a lack of a better term. And where there are empty places in the grid, produce a random terrain. If my knowledge of this were hightened by a large percent, I would surely help you with this amazing task.

Again, you have embarked in an area that indeed grabs the attention of many, I do think that the many are ultimately looking for a way to produce that wanted endless terrain.

In conclusion, what you have here is truly an amazing addon that really makes the production of these 3d worlds much easier. I can only commend you for putting this together and sharing it with the community, its truly wonderful.

Again, if ever there is anything you need me to do to assist you, please dont hesitate, I am at your call.