Gamestudio Links
Zorro Links
Newest Posts
loading historical data 1st time
by AndrewAMD. 04/14/23 12:54
Trade at bar open
by juanex. 04/13/23 19:43
Bug in Highpass2 filter
by rki. 04/13/23 09:54
Adding Limit Orders For IB
by scatters. 04/11/23 16:16
FisherN
by rki. 04/11/23 08:38
AUM Magazine
Latest Screens
SHADOW (2014)
DEAD TASTE
Tactics of World War I
Hecknex World
Who's Online Now
3 registered members (AndrewAMD, The_Judge, Grant), 898 guests, and 5 spiders.
Key: Admin, Global Mod, Mod
Newest Members
rki, FranzIII, indonesiae, The_Judge, storrealba
18919 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
Page 2 of 2 1 2
Re: Bug? c_trace: target doesn't hit ellipsoidal h [Re: jcl] #112536
03/07/07 20:48
03/07/07 20:48
Joined: Mar 2006
Posts: 3,538
WA, Australia
J
JibbSmart Offline OP
Expert
JibbSmart  Offline OP
Expert
J

Joined: Mar 2006
Posts: 3,538
WA, Australia
don't worry, i wasn't planning on using USE_BOX, just asking.

off to school now. i'll elaborate on this problem for the Engine forum users when i get home.

julz


Formerly known as JulzMighty.
I made KarBOOM!
Re: Bug? c_trace: target doesn't hit ellipsoidal h [Re: JibbSmart] #112537
03/11/07 10:45
03/11/07 10:45
Joined: Mar 2007
Posts: 75
Hamburg, Ger
Altimeter Offline
Junior Member
Altimeter  Offline
Junior Member

Joined: Mar 2007
Posts: 75
Hamburg, Ger
just some remarks:
obviousely you work with lite-c.
1.)Some of my problems came from using the temp variable, which is under c-script predefined as both vector and var. This temp is used very often in the scripts and is somehow like a 'whore', which is used by everybody and might bring you unpleasant features, if not used with care. With transition to Lite-c I created separate var temp1 and VECTOR* tempvec1. And I always zeroset them before use.
2.)Did you run your program both on C-script and c-light? Did you find a difference? I found a similar pbl in my project, which I currently transfer to Light-C. It used to work fine in C-script, under Light-c sometimes my ellipsoid hull is not 'obeyed'. But I contribute this to my programming (c-script was very 'forgiving errors'.
3.) for debugging pbls with c-trace I make my program draw a red 3d line between the various from- and to-vec (draw_line(.,.,.)). This is easy to do and gives a good idea, where the c_trace sometimes goes to.

Re: Bug? c_trace: target doesn't hit ellipsoidal h [Re: Altimeter] #112538
03/12/07 07:12
03/12/07 07:12
Joined: Mar 2006
Posts: 3,538
WA, Australia
J
JibbSmart Offline OP
Expert
JibbSmart  Offline OP
Expert
J

Joined: Mar 2006
Posts: 3,538
WA, Australia
i'll give the 3D line stuff a go tonight (i hope, very busy with school work atm). thanks very much for the response i'll get back to you with some shots of my results.

julz


Formerly known as JulzMighty.
I made KarBOOM!
[bug] c_trace goes too far [Re: JibbSmart] #112539
04/04/07 07:48
04/04/07 07:48
Joined: Mar 2006
Posts: 3,538
WA, Australia
J
JibbSmart Offline OP
Expert
JibbSmart  Offline OP
Expert
J

Joined: Mar 2006
Posts: 3,538
WA, Australia
alright, i haven't had time to try get this working properly since my last post, and i can't get the 3D line stuff working (line_3d or whatever is undocumented as it is in beta, and 2D line calculations aren't worth my time at the moment as i've already explained my workaround). my biggest problem is that people don't seem to understand the problem, and i didn't like this being dismissed as a coding error but i couldn't explain it well enough so i conceded to this topic being moved here. so i thought i'd give explaining it one last go:
Code:
vec_for_vertex(temp,me,g[d]);
vec_set(wheelpos[d][0],up);
vec_inverse(wheelpos[d][0]);
vec_normalize(wheelpos[d][0],48);
vec_add(wheelpos[d][0],temp);
result = c_trace(temp,wheelpos[d][0],IGNORE_ME|IGNORE_PASSENTS|IGNORE_PASSABLE);
debugger[d] = result;
you = wheel[d];
if(trace_hit)
{
gdist[d] = 4-result/12;
vec_set(you.x,target);
}

okay, that's basically a copy of the code from the first post, so it's easier for u (whoever reads this) to view as u read my explanation. that is exactly how it appeared in my script, except "[d]" was "[ i]", but [ i] makes things italics in this forum so that wasn't working so well.

variable details:

temp <- GLOBAL VECTOR
g[4] <- LOCAL ARRAY STORES THE VERTEX NUMBERS CORRESPONDING TO POINTS ON THE CAR EACH WHEEL PROTRUDES FROM
wheelpos[4][3] <- LOCAL 2-DIMENSIONAL ARRAY CONTAINING THE POSITION EACH WHEEL IS PROJECTED TOWARDS
result <- LENGTH OF C_TRACE
debugger[4] <- GLOBAL ARRAY DISPLAYED ON A PANEL
wheel[4] <- LOCAL ARRAY OF POINTERS POINTING TO EACH WHEEL
gdist[4] <- LOCAL ARRAY STORES THE PRESSURE ON EACH WHEEL, FROM 0 to 1.0

alright. i'm using lite-c, so multi-dimensional arrays and arrays of pointers are allowed. each wheel is passable, and so can not be seen by the c_trace. this snippet is contained within a while loop "while(d>0)" and the line just before the snippet is "d -= 1;". before the while loop, "d = 4;". this loop iterates through the above snippet for each wheel, basically.

for each wheel, it will get the global position of each vertex of the car that corresponds to the wheel's position with maximum pressure on it. basically, its like the suspension is completely pushed together. it then traces towards the point where the wheels should be with no pressure on them -- with the suspension fully extended. then, it puts the wheel at the target (which should be between these two positions) and sets gdist[d] (which contains the pressure on each wheel) to a percentage of pressure, where 0% means nothing was hit and 100% means the wheel is pressed up against the car as close as it can get.

i hope i explained that well enough, but either way, this always works perfectly. well, almost always. from what i can guess, c_trace checks for entities whose bounds mean they could be hit by a ray moving in the direction from vectorFrom to vectorTo. then it goes through those entities, and if they are further away than the distance between vectorFrom and vectorTo, they are skipped. the bug i'm experiencing is that some of them aren't getting skipped. my level, which consists of a model with its POLYGON flag turned on, has no problems with the car, and the car's wheels will only react if they get within 48 quants of the surface. that's good.

however, if the direction of the car's c_trace points towards my other car, which is using ellipsoidal collision, that car is still traced even if it isn't within range! the wheel jumps to that position, as far as 170 (roughly) quants away, even though the distance between vectorFrom and vectorTo is 48. this means c_trace is tracing in the direction from vectorFrom to vectorTo, but not stopping at vectorTo. additionally, this problem doesn't occur if the cars have their POLYGON flags set.

visually:
Code:

(car1)*------------* (car2)
//the first asterisk represents vectorFrom, the second asterisk represents
//vectorTo. the hyphens represent the c_trace, and "(car2)" is the other car.
//that's what should be happening, but instead:
(car1)*------------*-------------------(car2)
//the c_trace from car1 goes through vectorTo and continues until it hits car2, provided car2 is in that direction.



if you go through my code step by step, you'll see that result should never possibly be greater than 48, particularly with these lines:
Code:
vec_normalize(wheelpos[d][0],48);
vec_add(wheelpos[d][0],temp);
result = c_trace(temp,wheelpos[d][0],IGNORE_ME|IGNORE_PASSENTS|IGNORE_PASSABLE);


basically, it adds temp to another vector whose magnitude has to be 48 (coz of vec_normalize). this means the distance between these two vectors has to be 48. then c_trace traces between them, so result can never be greater than 48. sadly, it is anyway.

target is also set far away. it is set to exactly where c_trace would hit the other entity if its range was nearly 200.

i've worked around it by clamping result and adjusting "target" accordingly, but i'm sure this problem is slowing the engine down or something.

any ideas? is there really something i'm doing wrong?

thanks for reading, i know there's a ridiculously large amount there, a lot of it explaining the same stuff, but i wanted to explain it in every way i could to make sure people understood.

julz

Edit: i'm away for the next two weeks, so if someone replies and points out a stupid error on my part, my delayed response is not due to shame

Last edited by JulzMighty; 04/05/07 07:14.

Formerly known as JulzMighty.
I made KarBOOM!
Re: [bug] c_trace goes too far [Re: JibbSmart] #112540
04/09/07 09:36
04/09/07 09:36
Joined: Mar 2007
Posts: 75
Hamburg, Ger
Altimeter Offline
Junior Member
Altimeter  Offline
Junior Member

Joined: Mar 2007
Posts: 75
Hamburg, Ger
-concerning the 3dline you can find a working example in the template BipedPhy01.wdl, in the last para, within the the debugging stuff.

-for the c_trace problem:
If you can't solve your problem, you may think about a dirty workaround:
As long as it is only a few 'runaways', do something like:
result = c_trace (...)
if (result > 48){result = oldresult;}

The basic idea is to throw the unpleasant result away and replace it by the value of the previous loop (of course you should have saved this one somewhere before).
Depending on your game, you might also take the max value (kind of 'mechanical end-stop': result = 48), or you calculate the average value of your last 3 c_traces and replace your runaway with that.

Re: [bug] c_trace goes too far [Re: Altimeter] #112541
04/21/07 07:13
04/21/07 07:13
Joined: Mar 2006
Posts: 3,538
WA, Australia
J
JibbSmart Offline OP
Expert
JibbSmart  Offline OP
Expert
J

Joined: Mar 2006
Posts: 3,538
WA, Australia
im back!

and i already hav a decent workaround. but i appreciate the response mate u've had very few posts here and 2 of them were in response to my problem!

and i'll look at the 3d line example when i get the chance.

the workaround isn't a problem, i just suspect a bug and i dont want it to go unnoticed. it isn't a problem for me atm.

thanks,

julz


Formerly known as JulzMighty.
I made KarBOOM!
Page 2 of 2 1 2

Moderated by  HeelX, Spirit 

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1