terrain lod issue

Posted By: Wjbender

terrain lod issue - 09/19/14 11:41

terrain lod works for my terrains in pro ,but I have an
issue , I have used the tust library functions that alter
the terrain vertices based on a hightmap and when
my terrain lod is set at 0 , the heightmap is successfully applied to my terrain .

when I set my terrain lod at 4 , the lod works but
the heightmap is not applied , I need to be able to
have terrain lod and be able to apply height changes
successfully to my terrain ..

why would this happen ?

my terrain is 128 by 128 vertices with a 100 space between ..

a8 pro v8.30.5
has this been a bug with this version ?

it seems like the mesh is not being updated or lod not
re calculated for the new mesh vertices changes ,or is
there something else I should do instead of the usual
c.v.y and ent_setvertex calls ?

Posted By: FEL

Re: terrain lod issue - 09/19/14 13:51

a8 pro v8.30.5 - Why not using the newest version Oo that whole topic seems sensles. Just do an Update and see what happens.
Posted By: Wjbender

Re: terrain lod issue - 09/19/14 15:35

update ...freaking time I looked at the downloads page haha
Posted By: sivan

Re: terrain lod issue - 09/20/14 06:11

in earlier versions there were issues with vertex updates on c.v modifications.

to be honest I realized no speed increase when used terrain lod 2-4, comparing to when only terrain cache is applied (terrain lod 1), moreover I got a lot of shadowmapping issues because of the mesh and normals changes, thus I cannot use it over 1. (posted a question on the forum but nobody answered how they solve it)
Posted By: Wjbender

Re: terrain lod issue - 09/21/14 08:49

lod @ 4 works fine for me , with 9 tiles of terrain at 128x128 vertices per terrain tile ,I get at max about
100 fps sometimes , if I switched to lod @ 0 ,I get max
about 13 fps .

using camera.lod and d3d_lodfactor I can make the
fps more constant and acceptable for real time rendering on my low end laptop .

and I guess from lod 2 to 4 would depend on how detailed the initial terrain is ,plus how far everything is
rendered .

I haven't experimental with shaders on the terrains yet
but I know shadows would plummet my performance
waaay down ,I think also that the algorithm for landscape lod does not quite keep the outline shape
of hills /slopes very much the same while reducing in
between ,well I think that's true ,not sure .

I havw to agree that gs terrain is not quite very good
if we had to look at comparison ,like esenthel wich
is able to run at a blistering acceptable speed on my
laptop with the simple and forward renderer .

anyhow my laptop is not the best thing to be using
for this in the first place but this forces me to
make use of all kinds of optimizations.
Posted By: sivan

Re: terrain lod issue - 09/21/14 15:48

earlier I used very close lod distances, which was handled badly by terrain lod, resulted in too frequent switching, but 1-2 months ago I modified it, and tried it a few minutes ago, and now works a bit better... with farer lod distances it renders faster beside less shadow blinking, but requires further tweaking. (in a forest game situation it resulted in an increase from lowest 21 fps to lowest 27 fps)
Posted By: Wjbender

Re: terrain lod issue - 09/21/14 16:26

mmm and it is most definitely dependent on how
big terrain chunks are , it is a chunk based lod system ,I believe ?

I think i should determine my lod distance on chunk sizes
such that if I want 4 lods I would need to use a distance of view to include 4 chunks distances ,I think
the terrain system is quite flexible ,provided that chunks and total vertices and view distances can
be managed correctly ...

however as you mentioned with dense populated areas of meshes ,added to the scene it could become
a little problematic for a scene , I know we have lod
for models and these models would preferably be
rendered on their own draw distances ,depending
of course on how much of them is required in view.

i would manage such a system a bit like gta handled
its draw distances , models would have different draw
distances based on their type , ultimately this is not
enough for me in such a system ,I am working on
a mesh chunker to split meshes in to chunks of N triangles ,it should help me out when I need it .
Posted By: sivan

Re: terrain lod issue - 09/21/14 20:47

yes, chunk size does matter, 16 seems to result too frequent changes, 32 is a bit better, but I have found no optimal settings yet.

once I mentioned it would be great to have separate model and terrain lod distances, but nobody replied... oliver2s solved it by cycling through all the models, only about 100 per frame, and set their lod stage by code, maybe by ent_morph.
Posted By: Wjbender

Re: terrain lod issue - 09/21/14 21:31

that sounds like a viable alternative , uhm testing
my mesh chunker I determined that it is better to
have entities merged to reduce the amount of entities
than it is to have several entities as separate models.

I think you could most likely see a nice increase in
fps and decrease in memory by merging some clusters of entities ,either pre modeled as clusters or merged at runtime ,if you haven't done so already .

the mesh splitter I am working on for my projects should be useful
for large models that needs to be split into smaller
models , for instance static models over the triangle limit
could be split into separate models which conforms
to the limit, or large worlds into smaller chunks ..

I did not look in to this yet but I was thinking switching skins based on distance too ,however
I have no idea how that would impact performance ,negative or positive ..
Posted By: Wjbender

Re: terrain lod issue - 11/12/14 10:30

after updating I still have this problem , can someone
confirm that this does not happen to them ?

maby it's my fault .
Posted By: sivan

Re: terrain lod issue - 11/12/14 10:50

I can use my terrain deformer for lodded terrain in latest non-published MapBuilder (the deformer code is the same as for non-lodded terrain).

however, it uses a vertex based system, and sets all the lod0 vertices under the given area, even if a later lod of the chunk is visible. simply getvertex / set c.v.y / setvertex. and afterwards I set the normals to be proper by a function using c-tracings.

here is one that sets a constant height:

Code:
void	 	TerEdit_He_SetArea()										// not brush based
{
	if (proc_status(TerEdit_He_SetArea) > 0) return;
	
	// manage undo array counters
	teredit_he_undostep++;
	if (teredit_he_undostep>9)
		{
			teredit_he_undostep = 0;
		}
	if (teredit_he_undostep==teredit_he_firstundo)
		{
			teredit_he_firstundo++;
			if (teredit_he_firstundo>9)
				{
					teredit_he_firstundo = 0;
				}
		}
	//---------------------------
	// determine upper left and lower right vertex corners, i.e. get x,y vertex count within cube area
	
sys_marker("R01");	
	
	// x,y vertex size of terrain
	var vert_count_x = ent_status(terrain_entity,2)+1;	
	var vert_count_y = ent_status(terrain_entity,3)+1;
	
	// upleft and downright tile corner positions
	var upleft_pos_x = teredit_placement_cube.x - integer(teredit_tilesize/2)*GetMapTileSize();
	var upleft_pos_y = teredit_placement_cube.y + integer(teredit_tilesize/2)*GetMapTileSize();
	var upleft_pos_z = teredit_placement_cube.z; // PosInfo3D(upleft_pos_x, upleft_pos_y);
	
	var dnright_pos_x = teredit_placement_cube.x + integer(teredit_tilesize/2)*GetMapTileSize();
	var dnright_pos_y = teredit_placement_cube.y - integer(teredit_tilesize/2)*GetMapTileSize();
	var dnright_pos_z = teredit_placement_cube.z; // PosInfo3D(dnright_pos_x, dnright_pos_y);
	
	// corner vertices slosest to corner tile middles
	var upleft_vert  = ent_nextvertex(terrain_entity,vector(upleft_pos_x,upleft_pos_y,upleft_pos_z));
	var dnright_vert = ent_nextvertex(terrain_entity,vector(dnright_pos_x,dnright_pos_y,dnright_pos_z));
	
	// protection - no valid vertex found by ent_nextvertex
	if ((upleft_vert==(var)0) || (dnright_vert==(var)0))
		{
			return;
		}
		
	// vertices in a row & column
	var width_vert  = abs( dnright_vert%( ent_status(terrain_entity,2)+1 ) - upleft_vert%( ent_status(terrain_entity,2)+1 ) );
	var height_vert = abs( integer( dnright_vert /( ent_status(terrain_entity,2)+1 )) - integer( upleft_vert /( ent_status(terrain_entity,2)+1 )) );

sys_marker(NULL);
sys_marker("R02");

	// do vertex moves
	int i,j,k;
	var m;
	for (i=0;i<width_vert;i++)
		{
			for (j=0;j<height_vert;j++)
				{
					// vertex number
					k = upleft_vert +j*vert_count_x +i;
					// protection
					if (k>ent_status(terrain_entity,0))
						{
							break;
						}
										
					m = teredit_set;	// temp test - okay
					CONTACT* c = ent_getvertex(terrain_entity,NULL,k);   			// vertex number begins with 1 !
					c.v.y = (float)m;
					ent_setvertex(terrain_entity,c,k);
					
					// actual
//					teredit_vertexarray[k-1].actual = (var)c.v.y;	
					// new undo step
//					teredit_vertexarray[k-1].undo[teredit_he_undostep] = (var)c.v.y;				// BAD - whole evrtex array must be copied to not to keep non-corresponding data !
				}
		}
sys_marker(NULL);
	
	TerEdit_He_StoreUndoStep();
	
//	wait(1);
//	c_updatehull(terrain_entity,0);		// works fine but slow
//	ent_fixnormals(terrain_entity,0);	// not okay for chunked terrain - cause error around 1st chunk border

	wait(1);
	TerEdit_FixNormals_Area(upleft_vert,width_vert,height_vert,vert_count_x);
}

Posted By: Wjbender

Re: terrain lod issue - 11/12/14 12:12

I use the same functions , however I am using runtime
created terrain .

am I misreading the manual in ent_setvertex where
it states :

updating shared vertices of terrain chunks ,mesh seams ,OR LOD MESHES ,as well as updating the
visual bounding box AUTOMATICALLY HANDLED BY
ent_setvertex ...

however like I said when setting lod to 4 the terrain
remains flat(no vertices changed) with functional lod ,but setting lod to 0
the terrain vertices is changed successful and no lod.

why do I get the impression that this is a bug according to how I read the manual , lod should automatically update , but it is not doing this .

I know lod is automatically generated for loaded levels , but it also generates for created terrain ,the only issue is it does not allow me to change the terrain vertices with set_vertex ,leaving me with a
flat terrain with working lod wich is pretty useless ..

I am starting to think I would have to work with the
terrain meshes through theire mesh buffers if I
ever are going to get it working ,what a pitty .

jb
Posted By: sivan

Re: terrain lod issue - 11/12/14 12:50

I nearly never use created terrains, but plannig to use a heightmap based system to fine tune performance by setting terrain mesh resolution, so if you can make a simple example for Jcl he might help. he resolved when we reported the missing auto hull updating functionality.

currently only normals are not set automatically after vertex movements, but I think the engine default terrain vertex normal calculation is wrong, as my c-trace based solution looks very differently, and much better (except at some very sharp position which cannot be found in case of a real terrain).
Posted By: Wjbender

Re: terrain lod issue - 11/13/14 08:45

i found that the only way I can get setvertex to work
is by waiting 1 frame for every vertex change .
Posted By: sivan

Re: terrain lod issue - 11/13/14 10:33

very strange.
© 2024 lite-C Forums