 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Playing with creating some complex CSG parts in SDL, and wondering what the best
approach is.
My initial instinct is to use a prism - but I have a mixture of straight lines,
right-angle or 180-degree circular arcs, and radiused bends.
For simple splines, I could just concatenate them together, but I can't switch
between bezier, cubic, and linear splines midway through a prism definition.
But that would be a NICE feature. ;)
If I use a bezier or cubic spline for the prism, is there a trick to
manipulating the control points to switch between curved and "linear" domains?
I have a convex radius that then extends normal to the circle, some 90-deg
bends, ...
Maybe I should approach it a completely different way, but cobbling together a
dozen different bits by CSG seems --- tedious.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/5/19 4:33 PM, Bald Eagle wrote:
>
> Playing with creating some complex CSG parts in SDL, and wondering what the best
> approach is.
>
> My initial instinct is to use a prism - but I have a mixture of straight lines,
> right-angle or 180-degree circular arcs, and radiused bends.
> For simple splines, I could just concatenate them together, but I can't switch
> between bezier, cubic, and linear splines midway through a prism definition.
>
> But that would be a NICE feature. ;)
>
> If I use a bezier or cubic spline for the prism, is there a trick to
> manipulating the control points to switch between curved and "linear" domains?
Perhaps not understanding all you want, but a significant benefit of
bezier curves is that the control points for each segment are in the
middle and the end points are what they are.
To get a 'linear' bezier segment(1) make the control points linear with
the end points and space them equidistantly to the end points and each
other. In other words, treat linear bezier segments as 3 equal length
linear segments. (I'm pretty sure somebody wrote a linear to bezier
spline macro - with optional corner rounding I think - but I don't
remember where to find it at the moment...)
---
Aside: Yep, more extensive and more centralized spline support would be
cool. Today each primitive has its own collection of supported types.
See too hgpovray38 for an extended set of spline{} types.
Aside 2: For my own tool box I've a thought maybe a B-Spline
(sphere_sweep's b_spline), or perhaps Natural?, to all our other spline
types converter would be useful. Dump a collection of points (perhaps
pre-tweaked) as a spline type to get a c2/g2 continuity curve. Then
convert from that curve back to spline types our primitives support with
a more 'refined' higher point density(2) curve. If you run across
something like this as a standalone macro or program, please let me
know(3).
- I've learned some about splines in the past years especially, but
three's no doubt I'm still a hack. :-)
Bill P.
(1) - Yep not perfect given there will be numerical fuzziness, but that
somewhat true with all the spline types.
(2) - Shorter internal curve segments often help with numerical issues -
but how to generally get to improved representations..?
(3) Inkscape has inbuilt smoothing, but I've never dug into the code to
see if it's something I can easily use in a stand alone function/tool.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> wrote:
> Perhaps not understanding all you want, but a significant benefit of
> bezier curves is that the control points for each segment are in the
> middle and the end points are what they are.
>
> To get a 'linear' bezier segment(1) make the control points linear with
> the end points and space them equidistantly to the end points and each
> other. In other words, treat linear bezier segments as 3 equal length
> linear segments. (I'm pretty sure somebody wrote a linear to bezier
> spline macro - with optional corner rounding I think - but I don't
> remember where to find it at the moment...)
Right, but how do I roll up all of the linear and curved sections into a single
PRISM declaration?
To my knowledge, that is not currently possible.
It may be possible to abruptly switch between a pseudo-linear segment and a
pseudo-semicircular segment within the same spline with some very clever math,
but that's akin to trying to apply Thistlethwaite's algorithm to solving the
Rubik's cube.
So what I was envisioning was a prism object where you could do something like:
#declare DrawnComplexPrism =
prism {
linear
<vector[s]>,
cubic
<vector[s]>,
linear
<vector[s]>,
circular // would be nice to have a way to do this, to get true circular arcs
<vector[s]>,
linear
<vector[s]>
}
I have a few more parts to model, and I'll probably use some other methods to
hammer them out so that I have the code examples, but I just wanted to clarify
the idea.
Clearly there would issues with determining where the segments intersected,
since the list of vectors wouldn't necessarily explicitly define those.
POV-Ray solves for roots, perhaps future [experimental] versions could have
intersection solvers.
For instance, let's draw a right triangle, with a circle centered at the vertex
of the 90 degree angle. The perpendicular lines would represent - not absolute
line segments - but rays pointing toward the circular locus the user intends to
intersect.
The prism would then look like a triangle with a semi-circular bulge at one
corner.
I'm not sure what sorts of pathological cases might arise, but perhaps they can
be handled with error messages, allowing detached prism subsegments to coexist
(imagine if the circle and triangle did NOT overlap), and making use of of the
'inverse' keyword to switch between a default choice of one possible option vs
the remaining option (picture a circle overlapping TWO vertices of a narrow
triangle....
Again, just brainstorming and illustrating the idea for rapid construction of an
"extruded" type shape.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/8/19 2:42 PM, Bald Eagle wrote:
>
>
> Right, but how do I roll up all of the linear and curved sections into a single
> PRISM declaration?
The prism and lathe bezier spline can represent curved portions,
discontinuities in slope between curved portions and linear segments in
a single spline. Borrowing from the circle within a circle prism I
posted in answer to someone question a month or two ago:
#declare Cheese = srgb <1,0.65098,0>;
#declare Prism00 = prism {
bezier_spline
linear_sweep
-0.2, 0.2, 28,
<1,0>,<1,0.552285>,<0.552285,1>,<0,1>
<0,1>,<-0.552285,1>,<-1,0.552285>,<-1,0>
<-1,0>,<-1,-0.552285>,<-0.552285,-1>,<0,-1>
<0,-1>,<0.552285,-1>,<1,-0.552285>,<1,0>
<0.5,0>,<0.5,0.276143>,<0.276143,0.5>,<0,0.5>
<0,0.5>,<0,0.5-(0.5*(1/3))>,<0,0.5-(0.5*(2/3))>,<0,0> // a macro?
<0,0>,<0+(0.5*(1/3)),0>,<0+(0.5*(2/3)),0>,<0.5,0> // a macro?
pigment { color Cheese }
}
The last two bezier segments are linear; making the inner shape a slice
of pie so to speak. While working with an overall bezier spline you
could insert your linear parts with a macro where you'd specify only the
end points for the segment.
That said, I'm with you on your brainstorming in this direction(1) and
spline support could be better.
My belief is your particular proposal for supporting different stand
alone spline segment types to represent an overall prism shape won't
fly. In the POV-Ray code there would be too much context switching and
fuzziness as to what segments together constitute an enclosed region /
loop for it to be practical.
>
> Clearly there would issues with determining where the segments intersected,
> since the list of vectors wouldn't necessarily explicitly define those.
> POV-Ray solves for roots, perhaps future [experimental] versions could have
> intersection solvers.
>
The SDL trace() command was intended to be such a thing. Mostly, I see
people using trace() to put things on terrain or to grow things with
some avoidance of what objects are around. Attempting to create triangle
meshes from POV-Ray primitives another common use.
I see less use of trace() where people have created jig (tool) objects
for use with trace in creating other surfaces, splines and objects. It's
a different way of thinking about creating flexible models /
representations(1) and one I don't reach for enough.
>
> Again, just brainstorming and illustrating the idea for rapid construction of an
> "extruded" type shape.
>
Mostly for others - as I think you know, Inkscape is one tool that has
image -> POV-Ray prism(bezier) capability, but you have to bring it up
and use an interface. Years back the image -> prism export worked, but
was 'verbose' with respect to minimal bezier spline representations for
any given input image.
Bill P.
(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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I thought that prisms were no longer used.
Everyone has gone mesh triangles crazy.
Then someone asked about round prisms and I had to drop everything and do the
POV code. I had wrote a c++ windows program a long time ago to make Prisms and
polygons that I update it but never published. So for the last few days I've
been going though the code to see if I could add rounding to it.
Now you can along and I think maybe prism aren't dead. Now to the question:
William F Pokorny was right bezier prisms does it all you can linear parts and
curved parts in one prism.
> So what I was envisioning was a prism object where you could do something like:
>
> #declare DrawnComplexPrism =
> prism {
> linear
> <vector[s]>,
> cubic
> <vector[s]>,
> linear
> <vector[s]>,
> circular // would be nice to have a way to do this, to get true circular arcs
> <vector[s]>,
> linear
> <vector[s]>
> }
>
I can see in your the code above that we could cut it into several bezier
prisms union together. Each with its on variables. But if we wanted to make one
solid object then the borders between bezier object would have to match.
The big question is for the non linear prisms, do you want the code to make
point vectors or just make control vectors.
>
> I have a few more parts to model, and I'll probably use some other methods to
> hammer them out so that I have the code examples, but I just wanted to clarify
> the idea.
>
> Clearly there would issues with determining where the segments intersected,
> since the list of vectors wouldn't necessarily explicitly define those.
> POV-Ray solves for roots, perhaps future [experimental] versions could have
> intersection solvers.
>
> For instance, let's draw a right triangle, with a circle centered at the vertex
> of the 90 degree angle. The perpendicular lines would represent - not absolute
> line segments - but rays pointing toward the circular locus the user intends to
> intersect.
>
> The prism would then look like a triangle with a semi-circular bulge at one
> corner.
>
> I'm not sure what sorts of pathological cases might arise, but perhaps they can
> be handled with error messages, allowing detached prism subsegments to coexist
> (imagine if the circle and triangle did NOT overlap), and making use of of the
> 'inverse' keyword to switch between a default choice of one possible option vs
> the remaining option (picture a circle overlapping TWO vertices of a narrow
> triangle....
>
> Again, just brainstorming and illustrating the idea for rapid construction of an
> "extruded" type shape.
I'm lazy for Fast prisms I still use my old prism/polygon program. Even with
the upgrade it is small fast and does a lot. The one thing it is weak on is
accurate placement of points. It needs a total rewrite.
Its here:: http://leroyw.byethost15.com/
Have Fun!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> The prism and lathe bezier spline can represent curved portions,
> discontinuities in slope between curved portions and linear segments in
> a single spline.
Always back to Bezier. I will have to do some more thinking on this and see
what I come up with.
> My belief is your particular proposal for supporting different stand
> alone spline segment types to represent an overall prism shape won't
> fly. In the POV-Ray code there would be too much context switching and
> fuzziness as to what segments together constitute an enclosed region /
> loop for it to be practical.
I'm sure there are certain things that are probably too complex to do, esp if
they're hand-coded SDL rather than prism/spline definitions guided and
restricted to valid configurations by a GUI, but I have the gut feeling that
exploration in this area would yield dividends.
Perhaps the result would not be exactly what I proposed, but that's never really
the case, is it?
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.
Now, having said that, Leroy just chimed in right after you, and so I gave his
site a quick look. One of the things I noticed, given some work that I still
need to finish on the first part, is the pulley file. I think that if
something was put together to create a pulley/belt system - that would address
quite a lot of what I was after.
And it would serve double duty actually describing a pulley/belt system.
Throw in a twist to allow using 3+ sided "pulleys" and there's our linear bends.
And I have a nice little equation that allows making any N-sided shape. I can't
recall if I've posted that or not.
(I haven't tracked down the same in 3D --- yet)
Maybe I'll have a chance to work on this soon and make some progress.
It would be interesting to also address making other specific curves with Bezier
splines - sin, parabola, spiral - etc.
> (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.
----------------------------------------------------------------------------
2.2.1.6.4 Declaring User-Defined Vector Functions
Right now you may only declare vector functions using one of the special
function types. Supported types are transform and spline functions. For example:
#declare foo = function {
transform {
rotate <90, 0, 0>
scale 4
}
}
#declare myvector = foo(4, 3, 7);
#declare foo2 = function {
spline {
linear_spline
0.0, <0,0,0>
0.5, <1,0,0>
1.0, <0,0,0>
}
}
----------------------------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2019-10-09 à 13:57, William F Pokorny a écrit :
> On 10/8/19 2:42 PM, Bald Eagle wrote:
>>
>>
>> Right, but how do I roll up all of the linear and curved sections into
>> a single
>> PRISM declaration?
>
> The prism and lathe bezier spline can represent curved portions,
> discontinuities in slope between curved portions and linear segments in
> a single spline. Borrowing from the circle within a circle prism I
> posted in answer to someone question a month or two ago:
>
> #declare Cheese = srgb <1,0.65098,0>;
> #declare Prism00 = prism {
> bezier_spline
> linear_sweep
> -0.2, 0.2, 28,
> <1,0>,<1,0.552285>,<0.552285,1>,<0,1>
> <0,1>,<-0.552285,1>,<-1,0.552285>,<-1,0>
> <-1,0>,<-1,-0.552285>,<-0.552285,-1>,<0,-1>
> <0,-1>,<0.552285,-1>,<1,-0.552285>,<1,0>
> <0.5,0>,<0.5,0.276143>,<0.276143,0.5>,<0,0.5>
> <0,0.5>,<0,0.5-(0.5*(1/3))>,<0,0.5-(0.5*(2/3))>,<0,0> // a macro?
> <0,0>,<0+(0.5*(1/3)),0>,<0+(0.5*(2/3)),0>,<0.5,0> // a macro?
> pigment { color Cheese }
> }
>
> The last two bezier segments are linear; making the inner shape a slice
> of pie so to speak. While working with an overall bezier spline you
> could insert your linear parts with a macro where you'd specify only the
> end points for the segment.
>
> That said, I'm with you on your brainstorming in this direction(1) and
> spline support could be better.
>
> My belief is your particular proposal for supporting different stand
> alone spline segment types to represent an overall prism shape won't
> fly. In the POV-Ray code there would be too much context switching and
> fuzziness as to what segments together constitute an enclosed region /
> loop for it to be practical.
>
>>
>> Clearly there would issues with determining where the segments
>> intersected,
>> since the list of vectors wouldn't necessarily explicitly define those.
>> POV-Ray solves for roots, perhaps future [experimental] versions could
>> have
>> intersection solvers.
>>
>
> The SDL trace() command was intended to be such a thing. Mostly, I see
> people using trace() to put things on terrain or to grow things with
> some avoidance of what objects are around. Attempting to create triangle
> meshes from POV-Ray primitives another common use.
>
> I see less use of trace() where people have created jig (tool) objects
> for use with trace in creating other surfaces, splines and objects. It's
> a different way of thinking about creating flexible models /
> representations(1) and one I don't reach for enough.
>
>>
>> Again, just brainstorming and illustrating the idea for rapid
>> construction of an
>> "extruded" type shape.
>>
>
> Mostly for others - as I think you know, Inkscape is one tool that has
> image -> POV-Ray prism(bezier) capability, but you have to bring it up
> and use an interface. Years back the image -> prism export worked, but
> was 'verbose' with respect to minimal bezier spline representations for
> any given input image.
>
> Bill P.
>
> (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.
When using a beszer spline and I want a straight segment, I often do this :
...,PointA, PointB, PointA, PointB,...
That is, I use the end points of that segment as control points.
Why ? Simply because the length of the vector from a point and it's
control point don't matter in this case.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:web.5d98fe2acae70d394eec112d0@news.povray.org Bald Eagle wrote:
> My initial instinct is to use a prism
Can you draw it in inkscape and the export to POV-Ray?
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo <ing### [at] tagpovrayorg> wrote:
> in news:web.5d98fe2acae70d394eec112d0@news.povray.org Bald Eagle wrote:
>
> > My initial instinct is to use a prism
>
> Can you draw it in inkscape and the export to POV-Ray?
>
> Ingo
There's the possibility of doing something like that - though I have yet to find
anything that does it as good as VISIO.
I can draw circles, specify exactly where to move the center of the circle to,
exactly what radius I want, .... same with rectangles and all manner of other
shapes.
I can modify lines to give me a line of length L at exactly angle A, and move
the starting point to exactly <x,y>.
Everything I've experimented with so far as a replacement for VISO has been ---
lacking, and/or extremely unintuitive.
I'd like to stay out of M$ & windoze, but right now, if I need to draw it, then
it's probably easier to just shut down and reboot into Win7 and use VISIO, and
then reboot into Linux Mint to then use the drawings.
Maybe after I do a thorough disk cleanup / backup I'll look into installing
WINE, but I'm not there yet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
