![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 26-11-2012 22:27, Patrick Elliott wrote:
> Makes you seriously wonder, do these people not use anything else, or
> ever tried cheaper/free alternatives? Sigh...
Probably not... and/or they are jealously single minded about their own
proprietary app.
Thomas
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Jaime Vives Piqueres <jai### [at] ignorancia org> wrote:
>
> 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!
>
>
Am I missing something, or can't you already use the eval_pigment, then test it
against a volumetric grid of any precision you desire.
#macro eval_pigment(pigm, vec)
#local fn = function { pigment { pigm } }
#local result = (fn(vec.x, vec.y, vec.z));
result
#end
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Jaime Vives Piqueres <jai### [at] ignorancia org> wrote:
>>
>> 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!
>>
>>
>
> Am I missing something, or can't you already use the eval_pigment, then test it
> against a volumetric grid of any precision you desire.
>
>
>
> #macro eval_pigment(pigm, vec)
> #local fn = function { pigment { pigm } }
> #local result = (fn(vec.x, vec.y, vec.z));
> result
> #end
>
>
Yeah... but I would have to know what to do with the resulting points.
I prefer to have tessellation implemented in POV just as in LeForgeron
experiments: that would be very handy.
--
Jaime
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |