On 10/9/19 4:13 PM, Bald Eagle wrote:
> 
...
> 
> Always back to Bezier.   

It is a little of: "Have a hammer everything is a nail." :-) It's the 
hammer that exists today if you are trying to put everything in one 
prism declaration(1).

(1) - Not always best with any of the splines. As the internal segment 
counts get large, performance tends to slow.

> 
> Perhaps the result would not be exactly what I proposed, but that's never really
> the case, is it?

Agree. Nothing like trying something to show us what we don't know. (My 
recent isosurface issue, is starting to look like a tiling pattern - an 
any repeated pattern - issue on investigation. I almost never know what 
I'm really doing. :-) )

> I just have a sense that with all of the modelers out there, and the papers I've
> seen published on somewhat esoteric work, that maybe a method / code must exist
> already and it's just a matter of discovering and implementing it.
> 

My thinking at the moment isn't so much it not being doable - as it is 
just being really hard to do well. My head though is a mess of details I 
struggle to sort and set - always been so for me and it's gotten worse 
with age.

A detail I blew past trying to keep my response shorter than the 
rambling book chapters I tend to write. While my bet is still: "it's not 
worth the code complexity." A place we "might" buy something with your 
proposal is in allowing complete segment loops / enclosed regions to be 
represented as particular spline types. If, for example, we want to cut 
a square out a larger circular prism (cylinder like shape). Well then, 
representing the inner square as a linear_spline 'might' result in 
better performance - with the side effect it would be easier to describe 
what you want for a shape spline-wise. We've got csg though, so, do we 
win in the end...

Like you, I am thinking about 2d - 3d extrusion approaches & trying 
things - the density file patch. In suggesting use of B-Splines using 
some sample points from a 2d representation of whatever, I was tossing 
out my current thinking for a stable 2d to supported POV-Ray splines 
path, but I don't know how to do the spline type conversions / 
refinement. Finding the time to play with any potential solutions always 
an issue and why I've been hoping to stumble across some stand alone 
canned code/tool I can quickly understand and run as a batch command(2) 
/ tcl command.

(2) - I'm aware of potrace and years ago spent time playing with it. 
Checking now, looks like many updates since.

We want something good at creating a minimal number of spline segments 
while still representing the shapes well. We're in a ray tracer not 
creating svg or some other 2d vector result. The 2d image (I was doing 
svg -> firefox -> image for an svg path) to vector tools - when I last 
tried them - were all too verbose. The conversion worked, but 
performance wise / CSG wise in POV-Ray, yuck.

> 
> It would be interesting to also address making other specific curves with Bezier
> splines - sin, parabola, spiral - etc.
> 

Agree, would be good to have those methods in the toolbox.

> 
>> (1) I saw your suggestions for point lists and point list manipulation.
>> Good ideas I think which would help with 'trace() based jig methods'
>> among other things.
> 
> Yes, and just to add to that, when I was working on the vortex scene, I needed
> to do something along those lines and thought that maybe I could do something
> clever with functions, splines, and transform, but I got errors.  I'll have to
> see if there's any vestiges of that in the scrap pile, or maybe I can just take
> a crack at it again with new eyes.
> 

I have in my playpen, tcl, which implements a few of your point list 
ideas. I've not tried much in SDL(3). Point manipulation I think much 
easier in a language with good inbuilt 'list' support.

(3) - The density file patch includes an include where I implemented 
macros to write and read doubles as df3 files. It's a kludge because a 
df3 file is needed for each double of a vector. The idea was to have 
double storage available directly to functions and so accessible / 
manipulable by functions. I used the storage method for some depth map 
work at the time. I've have on my list to try user defined cameras with 
it. I think we could then transform user defined cameras in a general 
way - though I have doubts looping performance in SDL up to the task. 
For me, trying the idea first in tcl smarter, but I need to create tcl 
code to write my particular df3 double representation... Someday, maybe, 
I'll get to it...

Aside: The depth map patch gives us a direct way to transform any 
POV-Ray camera - or object - into an initial set of ray origins and 
directions for a user defined camera based on double storage.

> 

Anyway, need to get back to my isosurface / (mod)pattern debugging.

Bill P.

Post a reply to this message