PinkDot 0 Posted November 11, 2009 Report Share Posted November 11, 2009 I've encountered some problem with displaying NURBS func_splinemover. Spline is moved from the origin, although in game it works fine, I mean the bird does the same route, as before the issue appeared, so the engine sees it properly. on the first pic you can see that seagull and func_splinemover's origin are at the same spot, but the spline is offset. First (and last) vertex should be where the origin is. And another aspect of this issue - when I drag vertices, they move twice as much as a mouse pointer. See pic. 2 and 3: I don't know whether it's relevant or not but spline's origin coordinates have fraction numbers (1736.68 369.855 1056.89). Quote Link to post Share on other sites
Mortem Desino 66 Posted November 11, 2009 Report Share Posted November 11, 2009 First: the spline appears offset in DR because you removed the "model" spawnarg to get rid of the black box. The control points moving 2x as far as the mouse is a bug, but just a nuisance bug. It's alright for the spline info vectors to use fractions. Some of mine even end up with scientific notation (E.G. 1.6543648e23. The math to calculate vectors is so lightning-fast that it's not worth the time trying to normalize or simplify the coordinates. Quote yay seuss crease touss dome in ouss nose tair Link to post Share on other sites
PinkDot 0 Posted November 11, 2009 Author Report Share Posted November 11, 2009 First: the spline appears offset in DR because you removed the "model" spawnarg to get rid of the black box.I don't understand what's the relation between "model" spawnarg and spline's offset... Quote Link to post Share on other sites
greebo 29 Posted November 12, 2009 Report Share Posted November 12, 2009 Yeah, this seems to be a bug coming from the entity class refactoring I did some months ago. I never tested the curves, so this got to be tracked. Quote Link to post Share on other sites
Crispy 8 Posted November 12, 2009 Report Share Posted November 12, 2009 The math to calculate vectors is so lightning-fast that it's not worth the time trying to normalize or simplify the coordinates.Besides which, the FPU doesn't return values any faster if they're simpler - it takes a fixed number of cycles regardless of the values involved. Weird floating-point values can contribute to rounding errors in some circumstances, but in general these can be ignored unless they cause obvious issues. Quote My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares. Link to post Share on other sites
greebo 29 Posted November 20, 2009 Report Share Posted November 20, 2009 I fixed the curve manipulation problems in SVN, this will be resolved in the next release. Quote Link to post Share on other sites
PinkDot 0 Posted November 20, 2009 Author Report Share Posted November 20, 2009 Great! That was quick Greebo. I also noticed you resolved the entity def reloading issue. Many thanks! Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.