New Tiled Terrain Scene Node [works with Irr 1.5]

Announce new projects or updates of Irrlicht Engine related tools, games, and applications.
Also check the Wiki
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

sio2 >> OK now I see point. But problem is that my sectors are not all the same size. Thats why I divide terrain mesh in to 3x3 or 5x5 and not 2x2 or 4x4. If you let user to use any size he wish, you ofthen end up with mesh size which can not be divided in to 4x4 equal parts. If I use 5x5 sectors then center one can be diferent size from the rest and whole thing is still simetric.

For example try to divide number 7 in to 4 equal numbers ...impossible of course. But you can divide it like this: 1+1+3+1+1 ...as you see center one is diferent.

Bye the way I would be interesting in your version of isSectorOnScreen function if you dont mind ...can you post it here perhaps?
sio2
Competition winner
Posts: 1003
Joined: Thu Sep 21, 2006 5:33 pm
Location: UK

Post by sio2 »

arras wrote:sio2 >> OK now I see point. But problem is that my sectors are not all the same size. Thats why I divide terrain mesh in to 3x3 or 5x5 and not 2x2 or 4x4. If you let user to use any size he wish, you ofthen end up with mesh size which can not be divided in to 4x4 equal tiles. If I use 5x5 sectors then center one can be diferent size from the rest and whole thing is still simetric.

For example try to divide number 7 in to 4 equal numbers ...impossible of course. But you can divide it like this: 1+1+3+1+1 ...as you see center one is diferent.
How you split a single terrain up is irrelevant. What I'm getting at is that if, for example, you have a big world made up of NxN terrains then each terrain can use a single shared index buffer (sub-sectors organised however you wish) if each terrain is of the same dimension.

If the user is making their world from terrains of different sizes (shame on them!) then still, surely, the set of terrain sizes will be much smaller then the set of terrains. Just make a new index buffer for each new terrain size that comes long.

The alternative is an index buffer per-terrain. Complete waste of resources!
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

OK, for some reason I thought you refere to sectors of single terrain. Now I understand and you are right.
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

I have cleaned code for issues reported except signed-unsigned warnings so VS2005 will still complain. I dont have VS2005 so its hard to get rid of it for me. If somebody have will to correct it he is wellcomed.

I have also changed few things in demo. MCamera class was renamed to MCameraFPS and MInput was reworked and enhanced so it can detect both boolean keys and single key/button presses.

Debug key now switch between different debug modes.

Download at the begining of post.

I still cant get rid of setup window afther demo starts. If somebody know howe to close window afther device was droped and another one created, let me know.
Spintz
Posts: 1688
Joined: Thu Nov 04, 2004 3:25 pm

Post by Spintz »

If somebody know howe to close window afther device was droped and another one created, let me know.

Code: Select all

device->closeDevice();
device->run();
device->drop();
device = NULL;
Image
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

Thanks, It took me while untill I figured out that I need to call device->run() afther device->closeDevice(). Setup window is closing properly now. Download files were updated.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

I thought that Niko fixed this for the 1.3 release, or was it reverted due to some problems arising from this?! IIRC it's a problem of dangling events which fill up the event queue.
Spintz
Posts: 1688
Joined: Thu Nov 04, 2004 3:25 pm

Post by Spintz »

hybrid wrote:I thought that Niko fixed this for the 1.3 release, or was it reverted due to some problems arising from this?! IIRC it's a problem of dangling events which fill up the event queue.
It's not fixed, and yes it's something to do with the message system being improperly handled in CIrrDeviceWin32.

A breakdown of what's happening now -
  • Device->CloseDevice() calls DestroyWindow
  • Then, WndProc handles WM_DESTROY message by calling PostQuitMessage(0).
  • Then, the Device->run() function checks for the WM_QUIT message.
WM_DESTROY - http://msdn2.microsoft.com/en-us/library/ms632620.aspx -

Destroying the window, only destroys the GUI window. The console window remains. In order to get the console window to disappear, you need to "QUIT" the application.

WM_QUIT - http://msdn2.microsoft.com/en-us/library/ms632641.aspx

PostQuitMessage(0) does this, but only by causing GetMessage to return 0. PeekMessage and GetMessage are identical, except PeekMessage is non-blocking, where GetMessage is blocking.

Bah, who cares about all the details, if you want this fixed, change CIrrDeviceWin32::closeDevice() to -

Code: Select all

//! notifies the device that it should close itself
void CIrrDeviceWin32::closeDevice()
{
	DestroyWindow(HWnd);
	PostQuitMessage(0);
	MSG msg;
	GetMessage( &msg, NULL, WM_QUIT, WM_QUIT );
}
With this code, you only need to do -

Code: Select all

device->closeDevice();
device->drop();
device = NULL;
Image
FlyingIsFun1217
Posts: 219
Joined: Fri Apr 13, 2007 8:29 pm
Location: Illinois
Contact:

Post by FlyingIsFun1217 »

Call me stupid, but...
I assume you have to compile it in with the engine so that it is...part (?) of the .a file that you link to (I'm on linux). How? Placing the headers in the source directory, deleting the previous .a file, and recompiling doesn't work... :(

Thanks!
FlyingIsFun1217
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

I have no experience with compiling under Linux but you need your own Irrlicht.dll in your PATH somewhere to compile. Use dll which you use for other Irrlicht projects.

Irrlicht.dll and libIrrlicht.a which come with compiled demo are recompiled Irrlicht libs for Dev-C++ with Dx9 support. You dont need them to compile.

All files which are in ShTlTerrainSources070430.zip must be in your project directory + "media" directory which you can find in ShTlTerrainDemo070430.zip.
monkeycracks
Posts: 1029
Joined: Thu Apr 06, 2006 12:45 am
Location: Tennesee, USA
Contact:

Post by monkeycracks »

Well, I failed at making that editor. If someone else does it, that'd be wonderful.
BlindSide
Admin
Posts: 2821
Joined: Thu Dec 08, 2005 9:09 am
Location: NZ!

Post by BlindSide »

monkeycracks wrote:Well, I failed at making that editor. If someone else does it, that'd be wonderful.
You only fail when you quit trying.
FlyingIsFun1217
Posts: 219
Joined: Fri Apr 13, 2007 8:29 pm
Location: Illinois
Contact:

Post by FlyingIsFun1217 »

arras wrote:I have no experience with compiling under Linux but you need your own Irrlicht.dll in your PATH somewhere to compile. Use dll which you use for other Irrlicht projects.

Irrlicht.dll and libIrrlicht.a which come with compiled demo are recompiled Irrlicht libs for Dev-C++ with Dx9 support. You dont need them to compile.

All files which are in ShTlTerrainSources070430.zip must be in your project directory + "media" directory which you can find in ShTlTerrainDemo070430.zip.
Well your going to love me :)
In Linux, all it *seems* I need to compile a program successfully is the library file (.a) and the headers. Placing the headers in there correct spots (next to all of the other headers) gives me the error of:
main.cpp:(.text+0x158f): undefined reference to `ShTlTerrainSceneNode::ShTlTerrainSceneNode(irr::scene::ISceneManager*, unsigned int, unsigned int, float, unsigned int, irr::scene::ISceneNode*, int)'
Thanks for your help again!
FlyingIsFun1217
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

But of course you need a Linux version of the .a file - or none at all. It is usually best to simply link the .o files of your app with the libIrrlicht.a. Making a static library from your app does not really make sense.
So compile all .o files (with g++ -c ...) and link all .o files with Irrlicht and the rest of the libraries as in the example Makefiles
FlyingIsFun1217
Posts: 219
Joined: Fri Apr 13, 2007 8:29 pm
Location: Illinois
Contact:

Post by FlyingIsFun1217 »

Will try :)

Thanks!
FlyingIsFun1217
Post Reply