![]() |
bullet dynamics - Printable Version +- Forums (https://www.vdrift.net/Forum) +-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4) +--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9) +--- Thread: bullet dynamics (/showthread.php?tid=1262) |
- NaN - 05-09-2010 I compared the values to the first patch(closed track). The first row is correct(== last row of the first patch). It is the third row that is wrong. It should be somewhere between 213-211 for the z value. - alex25 - 05-09-2010 but obviously the racing line doesn't represent the actual surface vdrift sees: ![]() everything is red but the car still sinks in. --alex-- - NaN - 05-09-2010 The racing line is created from the corners of the patch. If the inner points are wrong(like for the rouen track) the car will sink. There must be a bug in their calculation. Is it also the last patch where the f1 sinks? - alex25 - 05-09-2010 it just happens that at rouen it is the last patch. in general they are all over the place (the interlagos one was the third one for example). and there is more than one patch that could be bad (there is plenty of them at suzuka, and monaco, etc.) how could we represent the inner points to visualize the bad patches? --alex-- - NaN - 05-09-2010 That is a bit more complicated as the surface doesn't have to match them. We need the interpolated values there. ![]() - alex25 - 05-09-2010 i've fixed the bezier surface for rouen in svn. also, instead of just using the corners to draw the road patch it would be nice to use the interpolated values as well to draw the surface vdrift actually sees. is it possible? - NaN - 05-09-2010 OMG, hacking in real time. This is a quick and dirty draw mesh through patch control points implementation. You will see buggy patches if they are visible from the bottom. You can adjust the trackoffset to a height you like. Bug example: ![]() Code: Code: void ROADPATCH::AddRacinglineScenenode(SCENENODE & node, ROADPATCH * nextpatch, I'll try to write down the interpolated version tomorrow. - alex25 - 05-09-2010 awesome job, but it looks like it highlights the next good patch and not the bad one: ![]() --alex-- - NaN - 05-10-2010 Quote:highlights the next good patchThe code simply draws the patches with 0.5 transparency. The highlighted section means there is some overlap(something wrong with the patches). To visualize the patch segments: Change uv-code to: Code: uvs[ui++] = y/3.0; ![]() In game: ![]() - alex25 - 05-10-2010 i wonder if we can integrate this functionality in the track editor and then we can see right away which patch is bad. additionally, it would be nice to have the ability to delete just one patch and then redo it, instead of having to re-trace the whole track. that would really speed up things. --alex-- - alex25 - 05-12-2010 so i think i pretty much fixed all the tracks (with the excpetion of ring2007). turns out, i didn't need to retrace the track, instead i could just load then into the track editor and save them right away and that would fix the bezier patches. not sure what happened the first time around. anyway, the only track this didn't work for is ring2007 (which was created with the latest version of the track editor). ring2007 uses quite extensively 3 and 4-vertex selection mode and i wonder if this confuses the collision routine (if it actually matters at all). --alex-- - NaN - 05-12-2010 Quote:if we can integrate this functionality in the track editorI had a look at the track editor code. I think it should be possible. Just need to find the time to do it. ![]() - alex25 - 05-12-2010 it's not that important. i thought the patches in the editor were wrong but it's most likely the bug happened when it wrote them out. - alex25 - 05-12-2010 if i try to change the bump amplitude for any of the track textures (corresponding to the bezier surface) nothing happens. actually it looks like none of the surface coefficients are being used. is that supposed to be so? removing the bezier surface makes the surfaces behave as i would want them. - NaN - 05-12-2010 Oops, I had no idea that we have surface data for the road surfaces. I think there has been some talk about using track geometry surface data for this. I'll have a look. |