possible bugs..

Posted By: Wjbender

possible bugs.. - 11/26/14 20:28

if I publish to a folder , it seems that cudart32_41_22.dll is not copied over in to the folder ,the engine then obviously complains about this ,I have to manually copy it .

something else that may be a bug also , when I create terrain at runtime or load terrain from file , and terrain lod is set above 0 , I cannot change the mesh with set_vertex , except for adding a frame wait of one for each vertex change inside the loop , if I didn't do it ,the terrain remains unchanged..

if I set terrain lod to zero ,I can apply vertex changes with set_vertex as usual but it means I have no lod for terrain .
in the manual I read that set_vertex automatically updates lod meshes .
it seems wrong to me somehow .

it would really help if wed-created regions could be iterated over from a list of type region ,instead of finding them by name perhaps ?

jb
Posted By: jcl

Re: possible bugs.. - 12/02/14 08:22

Thanks for the report! For automatically copying the right cudart DLL, please edit ackphysX.h and replace the file name in the PRAGMA_BIND statement. This will be fixed.

You can modify lod meshes with ent_setvertex. The change just needs 1 frame for being in effect on the terrain. So you can only modify the same vertex again in the next frame.
Posted By: Wjbender

Re: possible bugs.. - 12/02/14 14:27

thank you jcl , and sorry I meant ent_setvertex , well I guess it makes sense to have 1 frame of update time needed , I then only need to find a way to apply hightmaps faster because I am stepping 1 pixel at a time which obviously takes ages from 1 vertex to the next with a frame wait of 1 in real time per step , anyone have any advice on how to step directly to each vertex in distance vs the step amount on the heightmap image in pixels ?

jb
Posted By: jcl

Re: possible bugs.. - 12/04/14 08:40

What do you mean, "stepping 1 pixel at a time"? Mesh manipulation is very fast. There are many examples in the manual and the sample scripts for changing a mesh.
Posted By: Wjbender

Re: possible bugs.. - 12/04/14 11:51

I mean , if I need to apply a hightmap to a terrain with lod above 0 , if I had to step one pixel on the heightmap image to read its value ,then apply the height to the nearest vertex of the terrain ,how could I speed it up such that I skip directly to the next vertex instead of stepping 1 quant in 3d per pixel on the heightmap image ?

I have tried this but the wait(1) inside this loop makes it impossible for realtime , the reason I was trying to accomplish it in real time is because I wanted to generate terrains from coherent noise ,such that I only generate about 3x3 terrains at a time ,while moving through a large scale world ..

but ,I think it's going to be best to pre create the terrains and only load and unload them as I move through the world,because the fastest is to apply the hightmap on a terrain with lod set at 0 , then save it and then load it in the game with lod set above 0.

I thought the wait (1) and lod speed issue was clear from your response so what do you mean "what do I mean" ;-)
Posted By: jcl

Re: possible bugs.. - 12/04/14 11:55

I meant that I still did not understand your problem. A wait inside a loop is certainly very slow and definitely not a good idea, especially for mesh manipulation. Just check out the examples. Nowhere is a wait in a loop. I'm sure you can modify them easily for reading the heights from your heightmap image.
Posted By: Superku

Re: possible bugs.. - 12/04/14 13:59

Wjbender you currently go from heightmap data and try to convert that into mesh data, right? Why not just take a vertex position and calculate the corresponding pixel position, like
px = (int)(clamp((vertex.x-min_terrain_x)/size_terrain_x,0,1)*(bitmap_size_x-1);
then read the height at the position via pixel instructions?
Posted By: sivan

Re: possible bugs.. - 12/04/14 14:23

it works for me without waits, even with terrain lod:

Code:
int j;
	for (j=1; j<=ent_status(terrain_entity,0); j++)
		{
			CONTACT* c = ent_getvertex(terrain_entity,NULL,j);   			// vertex number begins with 1 !

			c.v.y += (float)worklevel;										// DirectX coordinate ! y up ! float !					
					
			ent_setvertex(terrain_entity,c,j);
			
											
		}



the only thing does not work is auto-update terrain vertex normals after deformation (which is not needed in case of the example above)
Posted By: Wjbender

Re: possible bugs.. - 12/04/14 16:58

since i havent worked with heightmaps before attempting this
i took a piece of code from the tust library that apply's the
heightmap to the terrain , it is this piece of code wich i cannot
understand why lod doesnt work with it unless a wait(1) is added .

the code in test_1 i took from the forum from sivan works fine
with lod bigger than 0 .

the code in test_2 is the one i attempted to use from a tust example
but it does not work with lod above 0, in test_3 you can see it works
fine with lod at 0 , in test_4 you can see it only works with lod above 0
if a wait(1) is added inside the loops ,why would this happen ? its not my own
code because i needed an example and i encountered the lod thingy with it ,so
i am not saying its supposed to work but i cannot quite understand why it does'nt ??


Code:
///////////////////////////////
#include <acknex.h>
#include <default.c>

//#define test_1 
//#define test_2
//#define test_3
//#define test_4

function main()
{
  	vec_set(screen_size,vector(800,600,0));
  	vec_set(screen_color,vector(50,1,1)); // dark blue
  	vec_set(sky_color,vector(50,1,1)); // dark blue
  	video_window(NULL,NULL,0,"terrain test");
 
  	level_load("");	
  	def_debug();
	def_move();
	
	vec_set(d3d_lodfactor,vector(1,2,3)); 

	BMAP* hm = "noise.jpg";

#ifdef test_1
	//test 1 works fine with lod>0
	terrain_lod=4;
#endif

#ifdef test_2
	//test 2 does not work with lod>0
	terrain_lod=4;
#endif

#ifdef test_3
	//test 3 is the same as test 2 but with lod==0 it works fine
	terrain_lod=0;
#endif

#ifdef test_4
	//test 4 is the same as test 2 but with a wait(1) in the loop is
	//needed for every update before it works ???
	terrain_lod=4;
#endif

	ENTITY *terrain=ent_createterrain(hm,nullvector,128,128,10);

//--------------------------------------------------------------

#ifdef test_1

	//works fine with lod >0

	int i=0;
	for(i;i<ent_status(terrain,0);i++)
	{
		CONTACT *pos=ent_getvertex(terrain,NULL,i);
		pos.v.y+=random(32);
		ent_setvertex(terrain,pos,i);
	}
	
#endif

//--------------------------------------------------------------

#ifdef test_2

	//does not work with lod>0

	int sx = bmap_width(hm);
	int sy = bmap_height(hm);
	int x=0,y=0;
	
	VECTOR pos;
	COLOR pixcol;

	var format = bmap_lock(hm, 0);	
	for(x=0; x<sx; x++) 
	{
		for(y=0; y<sx; y++) 
		{
			VECTOR* pos = vector(
				(terrain.x - terrain.min_x) - x * ((terrain.max_x - terrain.min_x) / sx),
				(terrain.y - terrain.min_y) - y * ((terrain.max_y - terrain.min_y) / sy),0);
				
			var v = ent_nextvertex(terrain, pos);
			CONTACT* cpos = ent_getvertex(terrain,NULL,v);

			var pix = pixel_for_bmap(hm, sx -x, y);
			pixel_to_vec(pixcol, NULL, format, pix);

			cpos.z = 0.1+(pixcol.blue );
			cpos.v=NULL;
			ent_setvertex(terrain,cpos,v);
		}
	}
	bmap_unlock(hm);	

#endif

//--------------------------------------------------------------

#ifdef test_3

	//the same as test 2 but with no lod it works fine

	int sx = bmap_width(hm);
	int sy = bmap_height(hm);
	int x=0,y=0;
	
	VECTOR pos;
	COLOR pixcol;

	var format = bmap_lock(hm, 0);	
	for(x=0; x<sx; x++) 
	{
		for(y=0; y<sx; y++) 
		{
			VECTOR* pos = vector(
				(terrain.x - terrain.min_x) - x * ((terrain.max_x - terrain.min_x) / sx),
				(terrain.y - terrain.min_y) - y * ((terrain.max_y - terrain.min_y) / sy),0);
				
			var v = ent_nextvertex(terrain, pos);
			CONTACT* cpos = ent_getvertex(terrain,NULL,v);

			var pix = pixel_for_bmap(hm, sx -x, y);
			pixel_to_vec(pixcol, NULL, format, pix);

			cpos.z = 0.1+(pixcol.blue );
			cpos.v=NULL;
			ent_setvertex(terrain,cpos,v);
		}
	}
	bmap_unlock(hm);	

#endif


//--------------------------------------------------------------

#ifdef test_4

	//the same as test 2 but needs a wait(1) in the loop before it works ??

	int sx = bmap_width(hm);
	int sy = bmap_height(hm);
	int x=0,y=0;
	
	VECTOR pos;
	COLOR pixcol;

	var format = bmap_lock(hm, 0);	
	for(x=0; x<sx; x++) 
	{
		for(y=0; y<sx; y++) 
		{
			VECTOR* pos = vector(
				(terrain.x - terrain.min_x) - x * ((terrain.max_x - terrain.min_x) / sx),
				(terrain.y - terrain.min_y) - y * ((terrain.max_y - terrain.min_y) / sy),0);
				
			var v = ent_nextvertex(terrain, pos);
			CONTACT* cpos = ent_getvertex(terrain,NULL,v);

			var pix = pixel_for_bmap(hm, sx -x, y);
			pixel_to_vec(pixcol, NULL, format, pix);

			cpos.z = 0.1+(pixcol.blue );
			cpos.v=NULL;
			ent_setvertex(terrain,cpos,v);
			
			wait(1);////why ???
		}
	}
	bmap_unlock(hm);	

#endif

}




uncomment the defines for each test
Posted By: Wjbender

Re: possible bugs.. - 12/05/14 07:09

@superku that sounds good ,working from the vertex side towards the bmap instead of the other way around , thanks I will try this out with iteration over the terrain vertices directly ,any way of doing something faster and more efficient is super in my book .
Posted By: sivan

Re: possible bugs.. - 12/05/14 10:24

not tried yet, just for the 1st sight is your vector declaration correct? I use VECTOR within functions instead of VECTOR*, and use always vec_set or other vec_ command.
Posted By: Wjbender

Re: possible bugs.. - 12/05/14 10:51

I got it to work by iterating directly over the vertices with ent_getvertex and then using a scale factor for the vertex positions into the bmap pixel positions .

it's fine like this ,lod works fine ,the heightmap is applied fine and the speed is fine jumping from vertex to vertex.

I dont know what's wrong with that code sivan ,maby its the ent_nextvertex or math section plugged into ent_nextvertex ..

a good feature would be if the height between one lod mesh to the next are morphed/interpolated or smoothly changed over time since height changes from one lod to the next is a sore thumb SOMETIMES ,if there is already such a feature I would like to make use of it ,just point me in the direction ,just a thought though.

jb

Posted By: Wjbender

Re: possible bugs.. - 12/05/14 21:43

another one I am not sure of , when I set terrain lod above 0 , and create a terrain with ent_createterrain ,I try to read the pixel off the terrain with terrain_getpixel .

all it does is return a script crash in terrain_pixel_for_pos no matter what I use as input for the terrain_getpixel function. .

it only works with terrain lod at 0

maby the bug is linked somehow..
Posted By: Wjbender

Re: possible bugs.. - 12/05/14 22:01

the exact same issue with terrain_setpixel with the exact same error message ,only works with terrain lod at 0
Posted By: Wjbender

Re: possible bugs.. - 12/06/14 07:32

I got the problem ! terrain bounds aren't automatically set , the terrain. max_x .min_x .max_y .min_y min_z max_z all give a result of 0 , if I use c_setminmax directly after terrain creation the terrain lod and everything works because the bounds are part of those calculated values used in the code parts I needed to use..

jb
© 2024 lite-C Forums