New Tiled Terrain Scene Node [works with Irr 1.5]
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?
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?
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.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.
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!
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
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.
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.
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;
It's not fixed, and yes it's something to do with the message system being improperly handled in CIrrDeviceWin32.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.
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.
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 );
}
Code: Select all
device->closeDevice();
device->drop();
device = NULL;
-
- Posts: 219
- Joined: Fri Apr 13, 2007 8:29 pm
- Location: Illinois
- Contact:
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.
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.
-
- Posts: 1029
- Joined: Thu Apr 06, 2006 12:45 am
- Location: Tennesee, USA
- Contact:
-
- Posts: 219
- Joined: Fri Apr 13, 2007 8:29 pm
- Location: Illinois
- Contact:
Well your going to love mearras 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.
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:
Thanks for your help again!main.cpp:(.text+0x158f): undefined reference to `ShTlTerrainSceneNode::ShTlTerrainSceneNode(irr::scene::ISceneManager*, unsigned int, unsigned int, float, unsigned int, irr::scene::ISceneNode*, int)'
FlyingIsFun1217
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
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
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
-
- Posts: 219
- Joined: Fri Apr 13, 2007 8:29 pm
- Location: Illinois
- Contact: