In article <web.46cddff26dc602ea47d3ae5e0@news.povray.org>, 
gee### [at] mailnu says...
> Well, what can I say. I'm starting to understand and I agree.
> 
> But I dont "expect" anything, I was just wondering how things worked. All
> users are not skilled programmers or patch-makers that knows what makes t
he
> clock tick. There are many advantages with POV-Ray, but what I miss is a 
way
> of sharing the created models to other platforms or for use in applicatio
ns.
> The greatness of POV-Ray itself doesnt change that, me now knowing that i
t
> is virtually impossible doesnt change it either.
> 
> But Im happy the rules for shaping 3d scenes are similar in the ground no
> matter the platform, and that POV-Ray has given me a understaning of that
> as well.
> 
I have, for some time, been rather annoyed by some limitations too. I 
recognize that POV-Ray is superior in a lot of ways. I also recognize 
that even when superior, there are some things that are complex, 
problematic and easier to do by using the *cheats* some other programs 
use, like subsurface scattering stuff, which makes skin look like real 
skin. Doing it the "right" way requires very nearly replicating the 
entire skeleton, fat layers, veins, subskin, etc. Well, not quite, but 
he more layers of "real" materials you add, the more accurate the 
result, you can't just "paint" approximations of the layers, then tell 
the problem to treat them as though they are at X depth, with some 
volumetrics or other tricks to make it look like the veins are 3D, when 
they are just painted. Some things are actually easier with scanline.

And for editors, the *best* is still probably Moray, but Moray never did 
have full *native* support for all features, correct coordinates for 
what the engine defaults to, mesh editing, or other needed things. 
Worse, until recently it didn't have even halfway decent approximations 
of the solid geometry, and while it does now do "some" of that right, it 
doesn't do all of it, lacking means to do difference an other tricks 
correctly.

We have imho needed something like the up and coming 4.0 for some time, 
if for no other reason that, without the underlying code being open less 
restricted, there is no real way to even try to fix these issues. I can 
easily imagine a program that has the edit window, display window(s) 
*and* true GUI object modeling features, not just a raw engine under 
Linux, or a text editor and engine on Windows, and an incomplete GUI 
editor, also only for windows. There is a huge gap. Its not an 
uncrossable one, but it requires that we have permission to do things 
with the code that we can't do more than wish for right now imho.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

> David Buck wrote:
> 
>> Very strange.  When POV-Ray was first written, there were no .obj, 
>> .mdl or .3ds formats.  POV-Ray used its own format which developed 
>> into a sophisticated programming language for scene design.  Because 
>> of this design, we are able to do amazing things with POV-Ray which 
>> can't be done with traditional scanline algorithms working on polygon 
>> meshes. The results can be breath-taking and are IMHO unrivaled in the 
>> scanline world.
> 
> Even Pixar's renderer turns to ray-tracing for some of its effects.
> 
> Regards,
> John

I thought it was all raytraced, at least for the final scenes.

Post a reply to this message

"RusHHouR" <gee### [at] mailnu> wrote:
> So... there are NO ways of converting an object consisting of several shapes
> made in POV-Ray to .obj, .mdl, .3ds, .any-bigger-standard-type-of-mesh?
IMO, it's possible and, at least conceptually, not too hard to convert an
arbitrary POV object into a mesh in SDL. Of course it's likely to be
dreadfully slow.
The algorithm could be more or less like this:
-manually bound the object if there is a difference or intersection
involved;
-find the unique sphere that passes through all the bounding box points;
-use the geodesic dome macro that was posted a while back to find points on
the bounding sphere. The number of points is user supplied, the bigger the
more detailed the mesh.
-Pick the first point on the sphere and shoot a single trace toward the
center of the bounding sphere: if no hit ensues, proceed to next geodesic
point; otherwise store the point returned by trace.
-Repeat for all points.
You now have a cloud of points. I haven't figured out how to transform them
in faces yet, but a possibility is to calculate the distance between
points, if it is less than an user supplied treshold, then the two points
form an edge.

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> On Wed, 22 Aug 2007 21:47:09 -0700, Tim Attwood wrote:
>
> > As for the web site, I'm sure Chris Cason has better things to do than
> > to check the links.
>
> Actually, a few of us took this on a few months ago - the links should
> all be good, even if to old programs no longer developed....?
>
> Jim

I believe the Cross Roads 3d link is broken though.

On top of:
http://www.povray.org/resources/links/3D_Programs/Conversion_Utilities/

Post a reply to this message

On Fri, 24 Aug 2007 14:38:20 -0400, RusHHouR wrote:

> I believe the Cross Roads 3d link is broken though.
> 
> On top of:
> http://www.povray.org/resources/links/3D_Programs/Conversion_Utilities/

Try:

http://web.archive.org/web/20060519111739/http://synapses.mcg.edu/tools/
xroads/xroads.stm

I used the Internet Archive for a lot of my validation - at least to 
determine where stuff moved to.  It *seemed* to download the program from 
there, but there was an error message saying the archive wasn't valid for 
me.  Maybe you'd have better luck, though.

Jim

Post a reply to this message

Grassblade wrote:
> "RusHHouR" <gee### [at] mailnu> wrote:
>> So... there are NO ways of converting an object consisting of several shapes
>> made in POV-Ray to .obj, .mdl, .3ds, .any-bigger-standard-type-of-mesh?
> IMO, it's possible and, at least conceptually, not too hard to convert an
> arbitrary POV object into a mesh in SDL. Of course it's likely to be
> dreadfully slow.
> The algorithm could be more or less like this:
> -manually bound the object if there is a difference or intersection
> involved;
> -find the unique sphere that passes through all the bounding box points;
> -use the geodesic dome macro that was posted a while back to find points on
> the bounding sphere. The number of points is user supplied, the bigger the
> more detailed the mesh.
> -Pick the first point on the sphere and shoot a single trace toward the
> center of the bounding sphere: if no hit ensues, proceed to next geodesic
> point; otherwise store the point returned by trace.
That only works for objects that are star convex. i.e. objects where for 
every point an outward pointing ray does not cut through the shape. It 
will never work for e.g. a Klein bottle.
> -Repeat for all points.
> You now have a cloud of points. I haven't figured out how to transform them
> in faces yet, 
When you do let me know. I need such an algorithm for many of my 
projects and so do many others. ;)
> but a possibility is to calculate the distance between
> points, if it is less than an user supplied treshold, then the two points
> form an edge.
 From experience I can tell you that that does not work.

Post a reply to this message

Nicolas Alvarez wrote:

> 
>> David Buck wrote:
>>
>>> Very strange.  When POV-Ray was first written, there were no .obj, 
>>> .mdl or .3ds formats.  POV-Ray used its own format which developed 
>>> into a sophisticated programming language for scene design.  Because 
>>> of this design, we are able to do amazing things with POV-Ray which 
>>> can't be done with traditional scanline algorithms working on polygon 
>>> meshes. The results can be breath-taking and are IMHO unrivaled in 
>>> the scanline world.
>>
>>
>> Even Pixar's renderer turns to ray-tracing for some of its effects.
> 
> I thought it was all raytraced, at least for the final scenes.

Ray tracing was added to their renderer for Cars.  Up until then their 
renderer was a z-buffer thingy.  Even now the ray-tracing is only used 
for shading reflective surfaces and ambient occlusion.  The ray-tracing 
is only used to trace objects near the reflective surface (for 
performance reasons); objects beyond that distance are represented using 
environment maps.  Things which are not reflective use other shading 
techniques.  Once the object is shaded it is z-buffered in regardless of 
how it was shaded.  You can find their papers at http://graphics.pixar.com

Regards,
John

Post a reply to this message

I know this answer is a little bit late, but I found Crossroads here:
http://www.pacranch.com/vrmlresources/indextools.html

hth...gjw

"Jim Henderson" <nos### [at] nospamcom> wrote in message
news:46cf2a81$1@news.povray.org...
> On Fri, 24 Aug 2007 14:38:20 -0400, RusHHouR wrote:
>
> > I believe the Cross Roads 3d link is broken though.
> >
> > On top of:
> > http://www.povray.org/resources/links/3D_Programs/Conversion_Utilities/
>
> Try:
>
> http://web.archive.org/web/20060519111739/http://synapses.mcg.edu/tools/
> xroads/xroads.stm
>
> I used the Internet Archive for a lot of my validation - at least to
> determine where stuff moved to.  It *seemed* to download the program from
> there, but there was an error message saying the archive wasn't valid for
> me.  Maybe you'd have better luck, though.
>
> Jim
>

Post a reply to this message

"sully323" <lws### [at] netwaycom> schreef in bericht 
news:web.46ce255d6dc602ea9bf20b490@news.povray.org...
> Interesting thread.....  I too, however, wish that I could take some of 
> the
> "things"  I have created in P.O.V. and place them into Bryce, or Poser,
> etc....
>
> I am no programmer, and have very limited math skills...most my modles are
> started in sPatch.   (I know I could start there to export for these other
> programs, but sPatch is so limited..it dosn't even export textures!)
>
>
> I spend way too much time converting from sPatch to POV to DXF to *.obj
> files to poser files to Bryce files, etc,etc,etc... then actually creating
> "art"....
>
> Any thoughts?
>
>

Seriously, I would advice to switch from sPatch to Wings3D at 
http://www.wings3d.com/. You will have much more possibilities than in 
sPatch (or Hamapatch, for that matter), and you will have uv mapping too. 
sPatch is totally archaic now, although it is possible to make very nice 
things with it.

Thomas

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Grassblade wrote:
> > -Pick the first point on the sphere and shoot a single trace toward the
> > center of the bounding sphere: if no hit ensues, proceed to next geodesic
> > point; otherwise store the point returned by trace.
> That only works for objects that are star convex. i.e. objects where for
> every point an outward pointing ray does not cut through the shape. It
> will never work for e.g. a Klein bottle.
Good point. Let's change it to : for a given point shoot trace; if it hits,
store position and shoot another trace from a point that is position +
epsilon further along the ray. Repeat until you have a satisfactory number
of hits (just in case the object has infinite intersections with the ray).
Then go to next ray.
> > -Repeat for all points.
> > You now have a cloud of points. I haven't figured out how to transform them
> > in faces yet,
> When you do let me know. I need such an algorithm for many of my
> projects and so do many others. ;)
I have skimmed through papers, and apparently there are at least three ways
of doing it:
-ball pivoting algorithm: a sphere of given radius is pivoted around an edge
until it hits a third point. Start with small radius sphere to get the finer
details and repeat as needed with bigger radiuses (see
http://citeseer.ist.psu.edu/bernardini99ballpivoting.html).
-an extrapolating method that projects cube vertices on the normal plane of
any given point of the point cloud. Since trace can also return normals, we
don't need to estimate it from the point cloud, which saves a step. Paper:
Surface reconstruction from unorganized points, available at
http://research.microsoft.com/~hoppe/#recon. There's even code in C++
available at that page.
-And a gazillion of papers based on Delaunay triangulation and/or its dual
Voronoy diagrams. Since crackle is based on voronoy sets, I was wondering if
it
was possible to somehow feed POVray the cloud point and let whatever
procedure handles voronoy diagrams do the dirty work. Lots of C/C++ codes
available at
http://www-users.informatik.rwth-aachen.de/~roberts/software.html.
I sure wish I knew C. :-(
> > but a possibility is to calculate the distance between
> > points, if it is less than an user supplied treshold, then the two points
> > form an edge.
>  From experience I can tell you that that does not work.
Ah, ok. I guess it would have been too easy. :-p

Post a reply to this message