I'm still dealing with trace() failures on lathe.  I've tried various
workarounds, but the most promising entails an inside() tests.

The attached scene file does inside() tests on a wine glass defined as a
Bézier lathe, with the following results:

Bounding box <-54.0, 0.0, -54.0> ... <54.0, 264.0, 54.0>
<0.0000, 265.0000, 0.0000> is outside.
<0.0000, 264.0000, 0.0000> is inside.
<0.0000, 263.0000, 0.0000> is outside.
<0.0000, 50.0000, 0.0000> is inside.
<60.0000, 264.0000, 0.0000> is outside.
<42.5000, 263.5000, 0.0000> is inside.

These tests are at, respectively:
  1. Along the central axis, above the height of the glass.
  2. Along the central axis, at exactly the height of the glass.
  3. Along the central axis, just below the height of the glass.
  4. Along the central axis, within the stem of the glass.
  5. At exactly the height of the glass, outside its bounding box.
  6. Within the rim of the glass.

The second test is inside neither the wall nor the stem of the glass;
the inside() function has given the wrong result!

My apologies for the procedural definition of the lathe object, but when
I print the values and use those to define the lathe, I cannot reproduce
the bug.

(I'm looking at having to tell my trace macro in advance whether or not
I'm starting the trace from within the object.  I don't like having to
tell a macro how to do its job.)

Post a reply to this message

Attachments:
Download 'inside_test.png' (16 KB) Download 'inside_test.pov.txt' (4 KB)

Preview of image 'inside_test.png'

On 5/3/25 17:14, Cousin Ricky wrote:
> The second test is inside neither the wall nor the stem of the glass;
> the inside() function has given the wrong result!
> 
> My apologies for the procedural definition of the lathe object, but when
> I print the values and use those to define the lathe, I cannot reproduce
> the bug.

I think you are likely hitting a numerical limitation. The lathe and sor 
objects are problematic where the equations to be solved end up with 
x,y,z aspects which are axis aligned. More specifically, where the 
equations to be solved see little or no change in x, y or z over the 
evaluated range. In such cases, the equation's curve never crosses 
through zero in a reliable way and it becomes difficult (or impossible) 
to find roots. Or sometimes, one finds too many roots due numerical noise.

Have you tried adding a very small rotation in say z? Maybe try 
something like: 'rotate z*1e-5'

Another test which could be interesting would be to use your lathe in an 
object pattern where you leave your lathe as is, but sweep a y plane 
through a range just about the problem coordinate. Using this, with an 
orthograpic camera(*) looking directly up or down at the y plane, we can 
probably get an idea how large the 'numerical void' is about your 
problem coordinate. Could be a disc, maybe a tiny dot. I don't remember 
how the inside test for the lathe is getting done.

Bill P.

(*) The orthographic camera itself exposes many of these kinds of... 
no-dimensional delta/change, numerical issues.

Post a reply to this message

On 5/3/25 18:49, William F Pokorny wrote:
> I think you are likely hitting a numerical limitation.

A couple minutes after hitting send I had the thought that maybe it is a 
root count thing. If the inside test is getting done by shooting a ray 
say in +x say, the number or roots might be collapsing to 1 where the 
ray just skims the upper lip of the glass...

A tiny rotation might well fix that sort of numerical issues too for 
coordinates near the axis of rotation - but in reality it would probably 
just move the problem regions around...

Bill P.

Aside: Inside tests with isosurfaces are more stable than many other 
shape types. Values at any location in space are either < threshold or 
not. There are no surface transit counting vagaries.

Post a reply to this message

On 2025-05-03 18:49 (-4), William F Pokorny wrote:
> 
> Have you tried adding a very small rotation in say z? Maybe try
> something like: 'rotate z*1e-5'

Which am I rotating?  The object or the point?  Or both?

Post a reply to this message

On 5/3/25 20:14, Cousin Ricky wrote:
> On 2025-05-03 18:49 (-4), William F Pokorny wrote:
>>
>> Have you tried adding a very small rotation in say z? Maybe try
>> something like: 'rotate z*1e-5'
> 
> Which am I rotating?  The object or the point?  Or both?
> 

The object. Try it just after 'sturm'.

Post a reply to this message

On 2025-05-03 20:48 (-4), William F Pokorny wrote:
> On 5/3/25 20:14, Cousin Ricky wrote:
>> On 2025-05-03 18:49 (-4), William F Pokorny wrote:
>>>
>>> Have you tried adding a very small rotation in say z? Maybe try
>>> something like: 'rotate z*1e-5'
>>
>> Which am I rotating?  The object or the point?  Or both?
>>
> 
> The object. Try it just after 'sturm'.

I would rather put the rotation in the macro.  I don't want to mess with
the object definition.

Post a reply to this message

On 5/3/25 23:47, Cousin Ricky wrote:
> I would rather put the rotation in the macro.  I don't want to mess with
> the object definition.

I woke up a bit ago and decided to take a quick look at the current yuqk 
code for the inside test in the lathe. It is doing a crossing test. 
Inserting some code to dump the counts, I get the following for your 
original scene:

Number of crossings = 0
Number of crossings = 1   <--
Number of crossings = 2
Number of crossings = 1
Number of crossings = 0
Number of crossings = 1
Bounding box <-54.0, 0.0, -54.0> ... <54.0, 264.0, 54.0>
<0.0000, 265.0000, 0.0000> is outside.
<0.0000, 264.0000, 0.0000> is inside.
<0.0000, 263.0000, 0.0000> is outside.
<0.0000, 50.0000, 0.0000> is inside.
<60.0000, 264.0000, 0.0000> is outside.
<42.5000, 263.5000, 0.0000> is inside.

I'm in the middle of another attempt at newer options parsing code so I 
won't now dig into it, but I had the thought we might try looking at the 
normal when there is one intersection.

As with the inside tests for meshes, maybe where the normal is 
perpendicular to the direction of the inside test, we discard those 
intersections?

The spline is getting looked at in segments; maybe this would sometimes 
cause problems with the intermediate points where segments meet? 
Thinking too of Bezier segments running essentially parallel or 
anti-parallel to the test direction.

Anyhow, back to options.

Bill P.

Post a reply to this message

hi,

Cousin Ricky <ric### [at] yahoocom> wrote:
> I'm still dealing with trace() failures on lathe.
> ...
> My apologies for the procedural definition of the lathe object, but when
> I print the values and use those to define the lathe, I cannot reproduce
> the bug.

I think that's a very interesting "data point".  why/where could or would the
respective result (the list of points) differ ?


regards, jr.

Post a reply to this message

On 2025-05-04 10:04 (-4), jr wrote:
> 
> Cousin Ricky <ric### [at] yahoocom> wrote:
>> I'm still dealing with trace() failures on lathe.
>> ...
>> My apologies for the procedural definition of the lathe object, but when
>> I print the values and use those to define the lathe, I cannot reproduce
>> the bug.
> 
> I think that's a very interesting "data point".  why/where could or would the
> respective result (the list of points) differ ?

Because the printed list of points is merely a decimal representation of
the procedural results; a discrepancy is almost inevitable.

Post a reply to this message

On 2025-05-03 19:09 (-4), William F Pokorny wrote:
> 
> Aside: Inside tests with isosurfaces are more stable than many other
> shape types. Values at any location in space are either < threshold or
> not. There are no surface transit counting vagaries.

Not that I have the patience to render a refractive object, such as a
wineglass, modeled with an isosurface...  Perhaps Chris might.

Post a reply to this message