nurbs sampling directly on the last knot

i’m having trouble with a nurbs system i’m building.

when i want to sample a point on top of the last knot the point is reduced to zero.

so say you have a nurbs surface parameterized by (0.0~1.0) in the u and v parametric ‘dimensions’. if i give it 1.0, i would like to get a point on the boundary, but i get zero.

i’ve tracked down the root cause of this in the code, but i’m wondering if this is mathematicly sound, or if i left out an equal sign or something in an inequality condition somewhere.

even if this is mathematicly accepted though, i would like an eloquent solution to handle this case somehow… preferably without having to always check for the boundary case that is.

i have difficulty expressing my code, because my development machine is not my internet terminal, and i have to go through a lot of steps to secure the two machines for a network transmission.

but basicly i’m using the standard textbook recusive spline algorithm right now. its clear that if the final few knots are equal (standard knot vector i believe), then a divide by zero will arise. i believe mathematicly this is a paradox or something, but the algorithm skirts this by checking for a zero, and effectively reduces the outgoing weight to zero… but for the end of the knot vector i would prefer the outgoing weight to be 1.0.

actually, the only aspect of ansi c++ i’ve put off familiarizing myself with too much is exception handling. would this be a great time to use it? would an exception handler even be faster than checking for zero? just throw on divide by zero… isn’t that how they work.

i’ve looked through exception handling code… but for some reason i just haven’t been into putting it in my own code. maybe it is time to start today.

is this a good idea?

c++ exception handling completely confounds me… that is why i’ve never used it… every time i try to i can’t make head or tail of it.

the docs i’m using are completely non-sensical. can anyone suggest a comprehensive c++ exception handling tutorial?

it doesn’t look like any kind of zero divide exception would help here anyhow.

can someone please help out with this one if you have experience with this matter?

there really isn’t a good way to hack it because the weights must sum to unity.

the only thing i can come up with is to offset the final knots by a machine epsilon type value and hope everything lines up.

adding an infitessimal offset to the final knots seems to do the trick for me (for now at least)… but it makes gluNurbsSurface produce funny results.

i don’t plan on using gluNurbsSurface, but i’m not happy with this solution.

i need something that isn’t a hack. but i can’t come up with anything.

gluNurbsSurface seems to be able to handle this case.

please any ideas?

Can I have your program to have a look if possible?

Originally posted by michagl:
[b]adding an infitessimal offset to the final knots seems to do the trick for me (for now at least)… but it makes gluNurbsSurface produce funny results.

i don’t plan on using gluNurbsSurface, but i’m not happy with this solution.

i need something that isn’t a hack. but i can’t come up with anything.

gluNurbsSurface seems to be able to handle this case.

please any ideas?[/b]

why may i ask?

unfortunately it would almost undoubtedly be a lot more trouble than its worth. to begin it takes me a lot of steps to transfer code to this machine. and my source is very tight and built on top of my own stock libraries built from scratch. the libraries are designed to be optimally intelligible, but i can’t share them.

if you are someone with experience with these matters though… if you could briefly explain how sampling on the final knot is traditionally accomplished you would have my apreciateion.

michagl its me again bonehead. all this stuff is summerized in the standard text.

no idea what you are talking about boneheadsan.

the trick is to not use the final knot value, subtract a small scalar say, 0.000001f from the final value. The problem is that the final knot value is part of the next curve segment, which is not part of the surface. The cox-de-boor algorithm will therefore consider it out of range and return zero.