1 registered members (AndrewAMD),
1,018
guests, and 6
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: ent_setvertex()
[Re: sivan]
#390869
01/05/12 14:05
01/05/12 14:05
|
Joined: Sep 2003
Posts: 6,861 Kiel (Germany)
Superku
Senior Expert
|
Senior Expert
Joined: Sep 2003
Posts: 6,861
Kiel (Germany)
|
Das Updaten der Kollisionshülle eines großen Terrains kann lange dauern. Um dem vorübergehend aus dem Weg zu gehen, setzen Sie das Flag PASSABLE des Terrains und setzen es im selben Framezyklus wieder zurück sobald die Terrainverformung fertig ist. Does the terrain's collision hull get updated by the end of the frame, too, when ent_setvertex has been called on passable terrain? (Probably not.)
"Falls das Resultat nicht einfach nur dermassen gut aussieht, sollten Sie nochmal von vorn anfangen..." - Manual Check out my new game: Pogostuck: Rage With Your Friends
|
|
|
Re: ent_setvertex()
[Re: jcl]
#390929
01/06/12 00:09
01/06/12 00:09
|
Joined: Sep 2003
Posts: 9,859
FBL
OP
Senior Expert
|
OP
Senior Expert
Joined: Sep 2003
Posts: 9,859
|
terrain_chunk = 0; is what I'm using and it DOES make a difference. if I set it to 0 I get unchunked terrain which supports ent_fixnormals. In A8. But if ent_fixnormals() will also work on chunked terrain in future, I have no problem switching to chunked terrain And yes, I did read the manual about ent_get/setvertex(). Left with the problem that the colission did not work and finding out that c_updatehull() fixes it. Had to do some forum search to get this answer.
Last edited by Firoball; 01/06/12 00:15.
|
|
|
Re: ent_setvertex()
[Re: FBL]
#390943
01/06/12 08:09
01/06/12 08:09
|
Joined: Mar 2011
Posts: 3,150 Budapest
sivan
Expert
|
Expert
Joined: Mar 2011
Posts: 3,150
Budapest
|
I checked level.c since it seems to be the best source. line 292 (last line of terrain_fence): c_updatehull(terrain,0); // adjust normal collision hull
my above mentioned problem (no hull update on chunk borders) is an A7 only phenomenon (since at my workplace I can use only A7 free), maybe caused by using ent_status(terrain,0) and not ent_status(terrain,1) for determining vertex quantity (results are 161*161 and 165*165 respectively if chunk size is 32 i.e. 5*5 chunks). but I don't know how to manage the duplicated vertices of chunk border edges... in A8 hull is updated properly by c_updatehull.
for fixing normals you can use simply c_trace, which sets hit.nx/y/z (or normal.x/y/z) and you can store it to c.v.nx/z/y. but it is not too fast at all, especially if you do not trace only the vertices, but all the neighouring faces and calculate an average of them. moreover, as I know if you want to get the same shading as produced by fixnormals or MED, there are 160 default normal vectors used for approximating real normals.
|
|
|
Re: ent_setvertex()
[Re: jcl]
#391035
01/07/12 03:33
01/07/12 03:33
|
Joined: Sep 2003
Posts: 9,859
FBL
OP
Senior Expert
|
OP
Senior Expert
Joined: Sep 2003
Posts: 9,859
|
A case where c_updatehull is required is when the terrain is deformed and something does a terrain collision within the same frame.
That might have been my problem. Thought I'veput enough wait(1) all over the code, but maybe I still had a gap somewhere. But why should colission not work with unchunked terrain in A8? That's what I'm doing... at least I'm using c_move and c_trace without problems...
|
|
|
Re: ent_setvertex()
[Re: jcl]
#398794
04/06/12 18:46
04/06/12 18:46
|
Joined: Nov 2004
Posts: 85 Deutschland, NRW, Eschweiler
annonymie
Junior Member
|
Junior Member
Joined: Nov 2004
Posts: 85
Deutschland, NRW, Eschweiler
|
ent_fixnormals is not required either, because it doesn't do anything with terrains. It's for models only. Thus, the normals of terrain must be set manually through the nx/y/z values. It would make sense to implement fixnormals for terrain also - in fact I see that it's already on our list.
To make my shader works right, I have also to set the terrain normals manually. To do that, I tried the follow:
c = ent_getvertex(terr, NULL, vertex);
vec_set(c.nx, vertex_normal);
ent_setvertex(terr, c, vertex);
Unfortunately the normals will not be changed... I don't know whats wrong, they all are still 0,0,1 although the normals I calculated have other directions. Please help
A8.30.5 Commercial
|
|
|
|