Quote: "Yes I checked it out."
LOL AWESOME!
Quote: "First I thought that it was only a plane but then I realized after moving around a bit that there are actually hills. Amazing."
Thanx! Yeah - That "plain" is just the black edges around the heightmap - it's pretty freaking huge! LOL)
Quote: "I think you should definitely increase the moving speed"
Well, you can hold SHIFT to go faster, and its inside the test_jgc_vmesh_bigterrain1.cpp file... near the bottom... (line 615 before changes) looks like:
JGC::Daddy->Update();
float cx; float cy; float cz;
if(!JGC::UserInput->MouseButton2 ){
JGC::Cam0->Control(0.05f,0.50f,0.1f,0.05f,JGC::Clock->Time_ElapsedFloat);
};
Those Cam Control Values effect speed... its an advanced version of the camera command that moves with the arrows(
dbControlCameraUsingArrowKeys() I think its called).
So you can speed it up.
Quote: "the terrain is so huge, more than 1.3 million polys!"
I presume you counted them by maxing out the camera LOL... yeah... Its big...
Quote: "I increased camera range and fog range and there were some strange clipping problems, but I think this is a directx problem.(Screenshot attached.)"
Never seen that before - I think it might of really pushed directX to the limit with the camera range out far enough to count 1.3 million POLY! Glad you're having fun with it!
Quote: "I haven't looked at the code in detail. How have you done the terrain? With memblocks or is it advanced terrain or something else?"
It starts in a memblock. That JGC_VMESH class is a multi-object, multi-limbed, "Matrix" on steroids
It has Welded Verts and a poly layout (modeled after Visigoth's USGS terrains.) That mesh is created by FIRST making a single poly for a "root" object (due to anomalies with how root behaves a bit different than limbs - and can look awful... for example... working on the mesh - if root 0 seems to be whole object - same for uv.. ) So I then create a mesh CellsX x CellsY (per limb) in a memblock.. then make a mesh from it, and then carbon copy it to fill the rest of the requested mesh size asked for. Cells are per limb - and need to even numbers due to the poly arrangement... 2x2, 4x2, 4x4, 16x2... Whatever ya need just even numbers for the cells. You also pick how many limbs per object (x,y), and how many objects (x,y) .... So its pretty dynamic.
There is also command to control UV and reset UV (to stock) for individual cells, and naturally, per limb, and per object, and per ENTIRE MESH... so makinging a level where you recycle a textures... and just
replace use detail textures where you need them.. well.. I suspect when I get to the level editor potion of all this for iron infantry - it'll be pretty neat.
Sorry to go on an on but you asked.
The reason the frame rates are so high with that mesh is because of the frustrum culling and that's BEFORE I added any quad or Oct tree processing to optimize it...however its using my frustrum "Regions" stuff ... which basically works like a 1 tiered Quadtree in that particular demo.
the Terrain (as far as frustrum is concerned) is broken into FOUR SQUARES... And these are each a region. if the REGION is not on the screen... then all the objects in the region are excluded - PERIOD, if the REGION is in the frustrum - then normal frustrum processing (Limb Frustrum culling in this case) is performed to see what (in that region) is really on the screen or not, hiding limbs that are not visible ...cuz it helps... and excluding objects that aren't visible... helps alot more LOL
.
So I hope that at least gives you some idea of what I'm doing so when you read the code - you'll know where its heading before you start.
Thanx for the report!
Best Regards,
Jason P Sage
