Sorry your browser is not supported!

Hi..

Is there a way to load an object piece by piece from disk? I need that to huge terrain..

Neils - I've done a lot of terrain code and your question is making me go "Twitch Twitch" and here's why...

Each Object is limited to I think somewhere around 10000 verts per mesh. An object CAN consist of more than one mesh - (limbs).

My first tip if you insist on trying to do the entire terrain in ONE object - is first make a triangle (1,1,1,1,1,1,1,1,1) (invisible ROOT Object is the result) and make each "chunk" a limb.

what I do with my terrains is make ONE square mesh the size I need, weld verts if necessary, in a memblock or what ever is need to get the weld to work.. then I make a mesh from memblock and use that like a rubber stamp for all the limbs. this mesh is limited to 100x100 cells to keep the vert count within DarkGDK's reach.

Once this flat checkerboard is created, you can manipulate the verts. you can also save the "completed" object as a DBO.

Be prepared, as you will have to contend with normals if the dbSetObjectNormals doesn't work for ya, you have to deal with texturing, FVF formats if you want shaders capable of addressing more than one texture on the same object, you need FVF format with UV, Specular maybe, TEX0, TEX1 etc... I just did a post today about FVF formats summerized - there is a C++ code snip of the values you add up to get the FVF format you need.

It's not simple - but its doable - so... again... Twitch Twitch and Good luck!
--Jason

@jason - I dont want to make all my terrain as one object. Right now I have 256 objects to make my terrain and I only need to load the nesseary objects. I want to use thread to load an object in small pieces and put it together as one when I need to.

I know that my terrain engine will change later but right now I just want to see if it will work

Shaders and multitextyre etc. is later

Aye Aye.

I'm under the impression that the DarkGDK entities are not thread safe - and frankly I can see why. The Object Entities for example are getting processed (if not excluded) during render, so a simultaneous thread accessing them (even if excluded - likely because the system that organizes then would have values changing during vertex locking) would be problematic.

Now some sort of loading in another thread might work if you have a memblock preallocated and load data and place the data into the memblock... but I suspect a LOADMEMBLOCK type call might be troublesome in this scenario - maybe not though.

I was able to multi-thread the Tokomak physics because of the separation that exists between Tokomak and DarkGDK. The Tokomak Physics Simulation "stepper" doesn't have any direct ties to DarkGDK so it works.

I have however seen some - what's the term - for that never ending terrain stuff... that could work though as the load is just points outside of view and the mesh itself is maniulated like a side scroller - or in the way you can scroll DarkGDK Matrix (move, then shift, and move back) to give illusion of smooth scrolling 3d terrain that really is just terrain around the viewer being manipulated.

I don't have an easy solution for you though, so I'll hush now and hope someone else has some more ideas. Visigoth, VanB, David W, IanM and DarkCoder are the likely canidates I'd suspect might have some good ideas for this - others too of course like Sid Sinister - but these are who come to mind at the moment.

--Jason

I can tell you what I would do, but it may be beyond what you can do right now - no offence intended, but it means getting dirty with DBPro object internals. This is also based on your requirement to have a single object per terrain block (although multiple limb objects containing multiple blocks would be more efficient).

I would probably use height maps of 64x64 - that number fits nicely into a single indexed mesh, so you don't need to work with multi-mesh objects, which makes things a little easier.

I'd pre-create all of the objects and exclude them. I'd also use a stack of unused objects, and a list of used objects.

I'd then prepare the objects so that the meshes are ready for immediate use - set up a grid of vertices with x, z, tu and tv components set correctly, indexes set up too.

Then when required, I'd load a heightmap, grab an object from the unused stack, populate the y coordinates from the heightmap, calculate the normals and populate those too, then position and unexclude the object.

You could make this more efficient by preprocessing the y coordinates and your normals into your own file format to avoid calculations at runtime.

Obviously, some of that is potentially threadable, but not all:
- getting the object pointer is not, but you can grab and store that when you create your objects initially.
- Positioning/texturing/unexcluding is not, but you can use a stack to store a 'todo' list of object preparation and carry it out just before you dbSync().
- Both your main thread and your loader thread need access to the unused stack (main to push items on, thread to take items off) and access to that needs to be serialised.

Look for Mikes presentation and code for loading objects from the 2007 convention - that shows how to update meshes directly.
Then take a look at Daves second presentation from the 2008 convention to see his explanation of how he does what you are trying to do.

Get your code working first in a non-threaded way before you attempt to get threading working.

And if you need some help, feel free to ask.

IanM - Thanks.... I will try.. I got an idea I will see if it works

I have all the terrain tiles as objects now, but as heightmap I can load them when I need... and then create the terrain...

That can work - I think they call those "R.O.A.M terrains" or something...

I bet you can pull it off!

--Jason