 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Jaime Vives Piqueres
Subject: Re: One more time: tessellation?
Date: 19 Nov 2012 05:01:27
Message: <50aa0377@news.povray.org>
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
