Hi All:

   I know this topic resurfaces every few months, but I just figured a
"Real Life" usage for it, and thought I should add one more argument to
the possible integration of tessellation into POV-Ray, as I found
LeForgeron has at least experimented with it:

http://wiki.povray.org/content/User:Le_Forgeron#Tesselation_.26_mesh_play
http://wiki.povray.org/content/User:Le_Forgeron#Mesh_from_and_to_file


   When I say RL, I mean something *really* practical: creating
placeholder meshes for physics simulations. Yeah, I'm deeply obsessed
with Bullet Physics, and I can't stop getting ideas related to it's
usage with POV-Ray via Koppi's Playground.

   The idea is that you have that reaaally nice and complex CSG,
isosurface, or any other non-mesh object, and you want to use it into
the physics simulation. Currently you are out of luck if it can't be
approximated with simple collision shapes, but even the most basic and
ugly tessellation will do a pretty god job in obtaining something that
will act as the "real thing" on the simulation...

   OMG, I'm already drooling!


--
Jaime

Post a reply to this message

Am 17.11.2012 10:47, schrieb Jaime Vives Piqueres:

>    The idea is that you have that reaaally nice and complex CSG,
> isosurface, or any other non-mesh object, and you want to use it into
> the physics simulation. Currently you are out of luck if it can't be
> approximated with simple collision shapes, but even the most basic and
> ugly tessellation will do a pretty god job in obtaining something that
> will act as the "real thing" on the simulation...

Maybe one way to get good tesselation would be to implement tesselation 
rules for each primitive, plus some algorithm to do CSG on meshes. Add 
to that a feature to dump any given object from SDL back into an .inc 
file (which would be a very neat feature of its own), use PoseRay to 
convert that .inc file to .obj, and we should be there.

Post a reply to this message

> Maybe one way to get good tesselation would be to implement
> tesselation rules for each primitive, plus some algorithm to do CSG
> on meshes. Add to that a feature to dump any given object from SDL
> back into an .inc file (which would be a very neat feature of its
> own), use PoseRay to convert that .inc file to .obj, and we should
> be there.

   Oops... yes, an ".inc dump" feature would be needed. I linked to Le
Forgeron "Mesh from and to file" experiments without noticing he used
the GTS format, which is not supported by Poseray.

   As for the tessellation itself, for my simulation purposes I guess it
would be enough with a general implementation. It doesn't need to be
nice, just close enough in shape. For the most complex objects you would
just increase the accuracy parameter to not miss important shape
features... it if gets slow, it doesn't really matter much, as you will
tessellate it only one time.

--
Jaime

Post a reply to this message

On 11/18/2012 11:28 PM, clipka wrote:
> Am 17.11.2012 10:47, schrieb Jaime Vives Piqueres:
>
>>    The idea is that you have that reaaally nice and complex CSG,
>> isosurface, or any other non-mesh object, and you want to use it into
>> the physics simulation. Currently you are out of luck if it can't be
>> approximated with simple collision shapes, but even the most basic and
>> ugly tessellation will do a pretty god job in obtaining something that
>> will act as the "real thing" on the simulation...
>
> Maybe one way to get good tesselation would be to implement tesselation
> rules for each primitive, plus some algorithm to do CSG on meshes. Add
> to that a feature to dump any given object from SDL back into an .inc
> file (which would be a very neat feature of its own), use PoseRay to
> convert that .inc file to .obj, and we should be there.
>
There is the open source (I think) CarveCSG, but there are some quirks 
in it, most of them resulting from intersection cases, where the parts 
being "carved" into/by, don't cross an edge. Sometimes it works, other 
times it looks like it works, until you try to do something, like UV 
mapping in an editor, and other times it just fails to work at all. 
Something would need to be done to test for such cases, and then 
adjust/correct for it, obviously.

Post a reply to this message

> There is the open source (I think) CarveCSG, but there are some quirks
> in it, most of them resulting from intersection cases, where the parts
> being "carved" into/by, don't cross an edge. Sometimes it works, other
> times it looks like it works, until you try to do something, like UV
> mapping in an editor, and other times it just fails to work at all.
> Something would need to be done to test for such cases, and then
> adjust/correct for it, obviously.

It may also be worth looking into how 3D CAD software works. They do 
exactly what you want, convert very complex CSG - often hundreds of 
levels deep - into triangle meshes suitable for the graphics card. They 
do this very robustly and have lots of control over the quality of the 
mesh and can automatically calculate mass/inertia etc - it seems 
perfectly suited.

A quick Google reveals that OpenCascade is a free core that does that, 
the only real task would be writing a converter from POV's primitives 
and CSG commands into a format that OpenCascade would understand. It 
would probably easiest be written as a patch to the POV binary that 
could then make use POV's internal data structures after the scene has 
been parsed.

Post a reply to this message

On 11/20/2012 4:41 AM, scott wrote:
>> There is the open source (I think) CarveCSG, but there are some quirks
>> in it, most of them resulting from intersection cases, where the parts
>> being "carved" into/by, don't cross an edge. Sometimes it works, other
>> times it looks like it works, until you try to do something, like UV
>> mapping in an editor, and other times it just fails to work at all.
>> Something would need to be done to test for such cases, and then
>> adjust/correct for it, obviously.
>
> It may also be worth looking into how 3D CAD software works. They do
> exactly what you want, convert very complex CSG - often hundreds of
> levels deep - into triangle meshes suitable for the graphics card. They
> do this very robustly and have lots of control over the quality of the
> mesh and can automatically calculate mass/inertia etc - it seems
> perfectly suited.
>
> A quick Google reveals that OpenCascade is a free core that does that,
> the only real task would be writing a converter from POV's primitives
> and CSG commands into a format that OpenCascade would understand. It
> would probably easiest be written as a patch to the POV binary that
> could then make use POV's internal data structures after the scene has
> been parsed.
>
Well, apparently, at least some bugs in CarveCSG have been corrected. I 
hadn't looked for an update for a while. Also.. in the case of the 
program I used it in, its not "imbedded", but actually drops the mesh 
out to a command line, then imports the result of the merge/cuts/etc. 
Which means, basically, that there may be things it can do, and tricks 
that are just not possible via the method being used to access it.

Post a reply to this message

>> A quick Google reveals that OpenCascade is a free core that does that,
>> the only real task would be writing a converter from POV's primitives
>> and CSG commands into a format that OpenCascade would understand. It
>> would probably easiest be written as a patch to the POV binary that
>> could then make use POV's internal data structures after the scene has
>> been parsed.
>>
> Well, apparently, at least some bugs in CarveCSG have been corrected. I
> hadn't looked for an update for a while. Also.. in the case of the
> program I used it in, its not "imbedded", but actually drops the mesh
> out to a command line, then imports the result of the merge/cuts/etc.
> Which means, basically, that there may be things it can do, and tricks
> that are just not possible via the method being used to access it.

It depends how sophisticated it is. I'm biased as I've only ever used 
commercial CAD packages, the free ones may not be as reliable or 
feature-rich, I haven't checked. But the packages I have used allow for 
all geometry POV has apart from isosurface-type things. If such a system 
was developed then a side-effect (or the main effect) would be a 
geometry preview possible on the graphics card :-)

Post a reply to this message

On 11/23/2012 12:17 AM, scott wrote:
>>> A quick Google reveals that OpenCascade is a free core that does that,
>>> the only real task would be writing a converter from POV's primitives
>>> and CSG commands into a format that OpenCascade would understand. It
>>> would probably easiest be written as a patch to the POV binary that
>>> could then make use POV's internal data structures after the scene has
>>> been parsed.
>>>
>> Well, apparently, at least some bugs in CarveCSG have been corrected. I
>> hadn't looked for an update for a while. Also.. in the case of the
>> program I used it in, its not "imbedded", but actually drops the mesh
>> out to a command line, then imports the result of the merge/cuts/etc.
>> Which means, basically, that there may be things it can do, and tricks
>> that are just not possible via the method being used to access it.
>
> It depends how sophisticated it is. I'm biased as I've only ever used
> commercial CAD packages, the free ones may not be as reliable or
> feature-rich, I haven't checked. But the packages I have used allow for
> all geometry POV has apart from isosurface-type things. If such a system
> was developed then a side-effect (or the main effect) would be a
> geometry preview possible on the graphics card :-)
>
Well.. As someone that can't afford the "commercial" ones, all I know 
about them is that they sometimes store things in ways that do not 
convert, and every damn one of them seems to have some proprietary 
format, making it impossible to import.

Damn 3D apps are like that too. There is this site, its all engineer 
types, and the objects are free, though there may be restrictions on 
some usage:

http://grabcad.com

but.. every damn one of this is, almost in all cases, is some format 
that **doesn't** have a translator, other than the very expensive 
program that made them (and, its not like you can keep downloading, and 
installing, demos, like you could in the old days, and get another 30 
days to work with).

Post a reply to this message

> Well.. As someone that can't afford the "commercial" ones,

I don't think many individuals can, or rather any would want to spend 
their own money on it. I certainly can't!

> all I know
> about them is that they sometimes store things in ways that do not
> convert, and every damn one of them seems to have some proprietary
> format, making it impossible to import.

There are 3 types of data structures most CAD software can load/save. 
The 1st is the native data to that piece of software, which is normally 
not compatible with other CAD software unless you have some expensive 
conversion software (it does exist). This type of data stores all the 
definitions of each step of the "building" process to get to the final 
model, all parameters, equations etc. It's a bit like having the SDL for 
a POV scene, once you have this you can easily make tweaks to the 
object. All CAD software has some form of API or scripting language to 
build up its native data, POV could make use of this if you wanted to 
convert POV SDL to CAD data for meshing or real-time display.

The 2nd type can be exported and imported by all CAD software and STEP 
or IGES is the common format used. STEP files hold mathematical 
definitions of all the geometry, but no information about how it was 
constructed. This type of data would be perfect for sending files from 
CAD to POV to be rendered, as no meshes are involved so quality would be 
perfect. In theory you could write a converter from STEP to SDL, but 
there isn't one I've found yet :-(

The 3rd type is a triangle mesh, all CAD software can import and export 
this, and is most often used to export to other software to be rendered. 
Obviously as it is an approximation to the true design you need to 
carefully choose the mesh settings in the CAD software when you export.

> Damn 3D apps are like that too. There is this site, its all engineer
> types, and the objects are free, though there may be restrictions on
> some usage:
>
> http://grabcad.com

Useful link, thanks. Your only real bet for POV use is the STL files, 
they are just triangle meshes and there is a converter stl2pov. For the 
STEP files you'll probably need something paid, as it's not trivial to 
mesh a STEP file...

Post a reply to this message

On 11/26/2012 12:25 AM, scott wrote:
>> Damn 3D apps are like that too. There is this site, its all engineer
>> types, and the objects are free, though there may be restrictions on
>> some usage:
>>
>> http://grabcad.com
>
> Useful link, thanks. Your only real bet for POV use is the STL files,
> they are just triangle meshes and there is a converter stl2pov. For the
> STEP files you'll probably need something paid, as it's not trivial to
> mesh a STEP file...
>
lol Its not even about POV use, its "use in general". There are a fair 
number of "standard" formats, which can be used by everything from 
Blender, to even the simple Erlang based Wings3D, to their own "high 
end" expensive CAD application. Yet, invariably, way too many of the 
things, and not just on this site, but others, are in some format you 
can't use. I had to, recently, download a demo copy of 3D Studio Max, 
because instead of outputting their "free" mesh in .3ds (loadable in 
many applications), they output it in .max (usable only *in* Max).

Makes you seriously wonder, do these people not use anything else, or 
ever tried cheaper/free alternatives? Sigh...

Post a reply to this message