Ok, finally i understood the very basics of collision, but i’d like to ask…
what is better, to
create a ray and a collision queue for each model, character etc
create just one dummy with a ray and queue, and use it to calculate collision for all models?
Thanks
c
I would think many rays … then you don’t need logic to move them each frame. But the best way to do it is to measure the stuff your self.
I am not even sure you can “create just one dummy with a ray and queue, and use it to calculate collision for all models”… having never done this.
well, since i’m planning a more than probably turn based game, i suppose that creating only one nodepath+ray+queuehandler and then parent it to the model who is going to calculate the collision would give better performance…
do you think that so?
the thing is -maybe i’m doing something wrong- but creating one ray for -lets say- just set the z value of a tree equal to the collision point to the terrain, it craps performance a lot…
i’m already working with the system i explained and is going fairly ok 
thanks anyway!
by the way, i’m using a modification of your script treeterrain.py -hope u don’t mind- for the multitexture thing, and really the only bad thing is that u have to put the texture meshes some +.z over the base mesh, wich gives a uuugly effect of semitransparent lines, i think u know what i mean…
could u give me some advice on how to approach the solution of this problem?
thanks again 
c
Just a small note: do not use rays on terrain. Its slow. Instead, figure out the height of the terrain by retrieving the pixel value of the heightmap. Both the HeightfieldTesselator and GeoMipTerrain can do that using getElevation.
mhmmm i see what u mean
ok, i’m not using none of geomipmap or tesselator at the moment,
just using my own generated simple terrain mesh,
but since i’m generating it from a heightmap bitmap i think i can figure out the elevation reading the greyscale of the pixel in given coords
thanks, that’s a good thought!
c
no, better reading the ‘h’ property of the list i already generated for constructing the terrain!
how i didn’t think that way in the beggining
arrghhh
of course, the mater is one pixel in the heightmap is one vertex between tiles in the terrain,
so i can only calculate the height of objects ‘snapedtothevertex’
so for objects ‘snapedtothetile’ or moveable objects i have to find some way.
i suppose i have to make some kind of calculation using the adjacents pixels that are more near to the character (?)
what do yu think? any equation in hand?
c
Right. You need to use linear interpolation for that.
Not hard to do, though. Look at this page:
en.wikipedia.org/wiki/Linear_interpolation
wow thanks, always good to learn something new
c
so if i’m not wrong in this case we are talking about Trilinear interpolation, isn’t it?
Could be either bilinear or trilinear. I think GeoMipTerrain uses bilinear, but trilinear could be even better. Bilinear is easier to do, though.
why not use pro’s terrain rather then wrote your own?
that’s a good question:
well, to tell the truth, pro suggested me to take a look to your treeterrain script for making multitexture tiles if i didn’t want to start writting shaders,
so my terrain is constructed based on the techinques you used there
probably i’ll change to pro terrain in the future but since i’m doing this for learning porposes i prefer to make things a bit directly and myself for a while, and also results are getting cute , with some problems aldough in the frames per second side 
for changing to pro terrain i first have to found a way to acces, manipulate and delete some vertex and triangles in it, for adapting your multitexture technique
in fact, i really think you 2 should work together in doing that in a serious way, geomipterrain with multitexture tiling based on a color map should be wonderfull, just what i -and probably many people- need 
Thanks for all, you 2 are making great work and support there
c
Hmm. Doesn’t sound like a bad idea. I might take a look at doing this.
great 