Hello,

I think I may perhaps remember various segments of conversation on this  
server over the years relating to the ability to convert a pov object to a  
mesh. I am not sure what happened with that. I remember one version for  
object export, which I care nothing about (save the conversion), and then  
other fragments about just converting regular objects to mesh.

My snow/icicle macro uses blobs; it looks great and parses very quickly.  
However, the blobs render so very, very, VERY slowly with interior of any  
kind, not to mention layered slope based material maps...we are talking  
WEEKS for the torus I posted in p.b.i if I use the high quality  
textures...only minutes for the one I posted. SSS will be used for the  
ultimate 3.7 final release of this...but that is not either here or there  
at this juncture.

What good is wonderful geometry if no one can use high quality textures  
with it?

For the final release I would very much like to follow something close to  
the process below:
1) Parse and create my snow/ice in memory (done)
2) Adaptively convert to mesh object (triangle or quadrangle or whatever  
gives the best results at the best time based on geometry)
3) Only render that mesh object, ignoring completely and garbage  
collecting if possible the original blob object. (even better, GC'ing  
adaptively as each object within an extinction radius is converted to mesh)

I would love to hear any good ideas that have a pov SDL or MathML (I can  
convert that to C#, and then to SDL) starting place. I would be even  
happier with something which already does this that I could just hack to  
suit.

That which follows is a bit of last ditch "brainstorm in the last 2 min"  
conjecture, that I really hope I won't need:
Is it possible to create an array of points and Trace() each to the  
surface of the object, so triangles or what-not are created and a mesh  
object would ultimately result?
Is Trace only viable for objects, and not Types?

Is this something that would require "obtaining" the geometry with an SDL  
raytracer that dumps optimized points to a mesh creation/optimization  
macro? (I really hope not..REALLY hope not..)

Thanks,
Ian

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Post a reply to this message

[GDS|Entropy] <gdsHYentropyAThotmailDTcom> wrote:
> 2) Adaptively convert to mesh object (triangle or quadrangle or whatever  
> gives the best results at the best time based on geometry)

  Tesselation is a hard problem. Blobs are relatively easy to tesselate
(because they are finite and don't contain hard edges), but the tesselation
algorithm itself is non-trivial. The so-called marching triangles algorithm
is probably the best one, so you might search for that (but, as said, be
aware that it's a complicated algorithm). In your case the algorithm will
have to be implemented in POV-Ray SDL.

  You can use the inside() function to determine if a point is inside or
outside an object (eg. your blob) and the trace() function to find the
surface. These can probably be used in the tesselation algorithm.

-- 
                                                          - Warp

Post a reply to this message

Am 11.12.2010 02:58, schrieb [GDS|Entropy]:

> Is this something that would require "obtaining" the geometry with an
> SDL raytracer that dumps optimized points to a mesh
> creation/optimization macro? (I really hope not..REALLY hope not..)

Normally yes - sorry.

But then again, POV-Ray has super-normal powers ;-)

One option that springs to my mind is to render an animation series of 
"slices" of the object, then use an external tool to trace the outlines 
of the shape in order to create a vertex cloud, and ultimately connect 
them to a mesh. Maybe do some sophisticated cleanup to reduce the vertex 
count where possible. Voila.

Post a reply to this message

Ah...man...errrrrgh...

So...a little practical advice would be in order here...

What would be the best course of action "in general"?
1) Create some sort of SDL raytracer which creates a mesh of my object  
 from scratch, so people can use realistic ice/snow textures with SSS and  
interior

or

2) Forget #1 and just perfect what I have, and put a big fat disclaimer  
about using any texture with IOR and filter/transmit, because single  
pixels can take a week or more..

or

3) Somehow find exemplars of macros which raytrace/mesh convert/export so  
I can Frankenstein something half respectable


So long as you do not use any fancy textures, this thing flies...

Given all I have going on I really don't think #1 is very practical if  
starting from absolute scratch.

#2 simply doesn't taste right to me...

Maybe if someone has retained a *good and simple* SDL raytracer sample,  
which I know has been posted at some time, *and* if I someone has a copy  
of a *good and simple* mesh converter, of which I also know exists and has  
been posted, #1 or #3 may become significantly more feasible. #3 looks  
best to me..

I know someone made a mesh object pov converter one time...but I don't  
know where to start in finding it..if I could just get my hands on those  
things previously listed, I know I could hack something together that  
would (probably with some advice from the community) get the job done and  
be re-usable for other macros in at least some capacity.

Does anyone remember the names of the files/who made, the sdl raytracers,  
mesh converters and export utilities I mentioned?

Ian McDonald


On Sat, 11 Dec 2010 15:06:47 -0500, clipka <ano### [at] anonymousorg> wrote:

> Am 11.12.2010 02:58, schrieb [GDS|Entropy]:
>
>> Is this something that would require "obtaining" the geometry with an
>> SDL raytracer that dumps optimized points to a mesh
>> creation/optimization macro? (I really hope not..REALLY hope not..)
>
> Normally yes - sorry.
>
> But then again, POV-Ray has super-normal powers ;-)
>
> One option that springs to my mind is to render an animation series of  
> "slices" of the object, then use an external tool to trace the outlines  
> of the shape in order to create a vertex cloud, and ultimately connect  
> them to a mesh. Maybe do some sophisticated cleanup to reduce the vertex  
> count where possible. Voila.


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Post a reply to this message

On 12/12/2010 07:06, clipka wrote:
> One option that springs to my mind is to render an animation series of 
> "slices" of the object, then use an external tool to trace the outlines 
> of the shape in order to create a vertex cloud, and ultimately connect 
> them to a mesh. Maybe do some sophisticated cleanup to reduce the vertex 
> count where possible. Voila.

The mesh camera with the max_distance setting could be used to probe an
entire blob in a single render. 

  http://wiki.povray.org/content/Documentation:Reference_Section_3#Max_Distance

Of course this doesn't solve the problem of getting the point cloud into
vertexes.

Post a reply to this message

On 11/12/2010 12:58, [GDS|Entropy] wrote:
> What good is wonderful geometry if no one can use high quality textures  
> with it?

are the textures you're using suitable for baking? (I see you are using
interior, so I'm guessing not).

if it seriously would take weeks to render at any reasonable resolution,
then it might be worthwhile for me to run the render in question under a
profiler to see where the time is being spent. however there's no chance of
that happening this year due to the pending release of 3.7.

-- Chris

Post a reply to this message

Interesting...quite interesting.

I wonder though; no matter the non-blob approach taken, it seems that when  
considering the textures, if one were to have two blobs of differing  
texture they would no longer "mix" as they do with blob objects. If this  
is the case then a lot of the realism gained through slope textures+blobs  
would be lost.

Ian

On Mon, 13 Dec 2010 22:28:21 -0500, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:

> On 12/12/2010 07:06, clipka wrote:
>> One option that springs to my mind is to render an animation series of
>> "slices" of the object, then use an external tool to trace the outlines
>> of the shape in order to create a vertex cloud, and ultimately connect
>> them to a mesh. Maybe do some sophisticated cleanup to reduce the vertex
>> count where possible. Voila.
>
> The mesh camera with the max_distance setting could be used to probe an
> entire blob in a single render.
>
>   http://wiki.povray.org/content/Documentation:Reference_Section_3#Max_Distance
>
> Of course this doesn't solve the problem of getting the point cloud into
> vertexes.


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Post a reply to this message

It has taken 4 days to render 1 pixel that I am now looking at. :(

I do not think the textures would bake well, as they are slope based and  
use interior, in addition to the fact they are designed to be blended by  
the "blobbing" of differently textured blobs.

However the profiler idea is very interesting.

I have converted a beta of this to pov 3.7 but it blows up during  
parse/just before render with an "unspecified error"; this was attempted  
using only a pigment of <1,1,1> and nothing more complex. No syntax errors  
encountered. The MegaPov #set keyword is the only non-standard feature  
used; #local works fine with 3.6 but not 3.7 when I tested, if I recall  
correctly.

Ian

On Mon, 13 Dec 2010 22:36:36 -0500, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:

> On 11/12/2010 12:58, [GDS|Entropy] wrote:
>> What good is wonderful geometry if no one can use high quality textures
>> with it?
>
> are the textures you're using suitable for baking? (I see you are using
> interior, so I'm guessing not).
>
> if it seriously would take weeks to render at any reasonable resolution,
> then it might be worthwhile for me to run the render in question under a
> profiler to see where the time is being spent. however there's no chance  
> of
> that happening this year due to the pending release of 3.7.
>
> -- Chris


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Post a reply to this message

Ok; very good then. I know someone has already made something of this sort  
here...and I have seen a number of c# versions.

My snow/icicle macro already uses trace and inside, but I was quite  
unaware that a point was a valid parameter of the inside method; I thought  
that it only accepted objects. I guess pov has overloads too. ;)

I have noticed a pattern...almost everything I want to do with a computer  
involves complicated stuff that hasn't been implemented yet lol! ;)

Ian

On Sat, 11 Dec 2010 05:07:45 -0500, Warp <war### [at] tagpovrayorg> wrote:

> [GDS|Entropy] <gdsHYentropyAThotmailDTcom> wrote:
>> 2) Adaptively convert to mesh object (triangle or quadrangle or whatever
>> gives the best results at the best time based on geometry)
>
>   Tesselation is a hard problem. Blobs are relatively easy to tesselate
> (because they are finite and don't contain hard edges), but the  
> tesselation
> algorithm itself is non-trivial. The so-called marching triangles  
> algorithm
> is probably the best one, so you might search for that (but, as said, be
> aware that it's a complicated algorithm). In your case the algorithm will
> have to be implemented in POV-Ray SDL.
>
>   You can use the inside() function to determine if a point is inside or
> outside an object (eg. your blob) and the trace() function to find the
> surface. These can probably be used in the tesselation algorithm.
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Post a reply to this message

Am 14.12.2010 05:05, schrieb [GDS|Entropy]:
> Interesting...quite interesting.
>
> I wonder though; no matter the non-blob approach taken, it seems that
> when considering the textures, if one were to have two blobs of
> differing texture they would no longer "mix" as they do with blob
> objects. If this is the case then a lot of the realism gained through
> slope textures+blobs would be lost.

You could do a render with the different textures replaced by simple 
pigments "red 1", "green 1" and "blue 1", respectively. The resulting 
data could be used as a basis for a texture_map to apply to the mesh via 
UV mapping.

Post a reply to this message