|
|
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
|
|