Working around CGAL color limitations, mesh post processing.

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Working around CGAL color limitations, mesh post processing.

ufomorace
Presently OpenSCAD doesnt support color render files.

Industry standard seems to be VRML2 and X3D, either color polygons or UV colors.

I'm thinking of putting together a code which can compare the triangles of an original colored mesh and the openscad CGAL mesh, find matching vertices and coincident polygons, and color them based on the input file.

That is where it gets complex, perhaps you can provide advice on different coincident-polygon comparisons, and potential pitfalls.

First I have to obtain openscad STL and the colored mesh so that they can exist in the same mesh engine, with a list of triangles and vertices and colors in arrays.

We already have that within openscad, except that i am a n00b programmer so i would probably code it on another mesh engine. Then i have to get a VRML2 conversion code. I have to compare every polygon in one mesh to every polygon in another mesh, to see if they exist on the same plane? If yes, to see if they overlap as triangles? If they do share the same space then it's safe to presume that they should be the same color, and thus to color the entire openscad mesh and save it as VRML2.

Please advise me on the difficulties of the task? :) Is there any reason why CGAL won't one day implement a similar post processing for colored mesh?


Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

ufomorace
Wiki says that X3D is the newest generation of VRML format. Meshlab and Blender source code perhaps contain good examples of X3D file conversion. I have found a conversion code for unity3D called unityx3d, so i could probably do it all in Unity3d in a couple of days, the result would be a bit impractical.
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

Neon22
Personally I think this is a stopgap measure until - as they have indicated - OpenSCAD eventually supports this feature (primarily for multiple extruders).
So I'd have to say use a simple format to do this and not such a complex format.
Specifically I suggest obj, or the proposed amf, as an export. But it depends on what your final use is for this file and what that app needs.
 - IMHO VRML1,2 is out and X3D is a massive pile 99% of which you don't need.
 - OBJ is read by everyone especially if you keep it simple which in this case I believe it would be.
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

Neon22
more discussion has been had on amf, 3mf and color in these two posts (at least):
- http://forum.openscad.org/Now-in-color-td13392.html
- http://forum.openscad.org/New-3MF-file-format-td12525.html
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

bobc
In reply to this post by ufomorace
It sounds a little complicated, I'm not sure if it would work. Where is the original colored mesh derived from?

I have a version of OpenSCAD which implements rendered color, it use Carve library so is also quite a bit faster than CGAL, although several useful features of CGAL are not supported such as hull, minkowski. It can output multiple STLs (one per color), or an AMF with one color per volume. I would like to add other formats such as X3D.

To guide development it would be useful to have more use cases. So if you have any sample models, and what the output mesh is to be used for, please let me know.
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

ufomorace
Hi Bobc, a carve version sounds ingenous. There is color by vertex and by polygon and by uvs, i have found that PLY also does color by vertex, it's a surprise to me, i was just thinking of color by triangle only because it is a clear contrast. Shapeways seems to only accept vrml2 and x3d files for color. It's to render any kinds of unions made with different color cubes. i was hoping to print variations of this code in color:
https://dl.dropboxusercontent.com/u/114667999/randfms.scad

Neon22, yes it's a bit unwieldy x3d given all the xml, ill have to triple my magnesium supplements prior to reading the specifications doc :D I will have to read what they say on the discussion page as it sounds confusing. It's much more difficult for me to understand a programming library to find where the triangles and indices are kept than to actually write code to compare all the source file triangles to the rendered file and copy the rendered file ones so that they are the same as the input colors.
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

ufomorace
So i am checking this X3D format controversy. So far it's fascinating. Attempting to save a cube file with different colors on different faces, at first glance it would be very easy to make an X3D file parser that saves suitable files from .scad renders:

The X3D header and footer definition code can be only 4-5 lines:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE X3D PUBLIC "http://www.web3d.org/specifications/x3d-3.3.dtd" "">
<X3D>
<Scene>
<Shape>
                 //some vertex and color arrays, see example1.x3dexample1.x3d
</Shape>
</Scene>
</X3D>

color by vertex has to be set to false and there has to be a colorIndex array, perhaps there has to be multiple materials in the X3D it said.

If you have Blender, you can make a color cube and save as X3D as an example file, and then copy the beginning and end text into an x3d parsing routing and write the arrays differently. I don't have blender i would be happy if someone sends a multi material x3d file.

Afterwards, I found out what X3D is all about. it can save concise 3d files, and it can also display 3d files in crazy ways in smartphones and web browsers.

It's an amazing file format, it can contain alot of lighting and scene information and even do some kinds of extrusion of pentagons and stuff...

I found this amazing page with examples, i am going to attempt to turn this into a colored cube and then i can write x3d parsing program. i write very simple code so anything i do with triangle indices post processing of an STL should be easy to port to openSCAD.

From this page of examples i found this and this... Amazing file format. It is equivalent to VRML2 for our 3d kinds of files, they are both fine formats.

Ok the name X3D is boring, so i will just have to put on my 3dkini and play some netbool :D
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

ufomorace
In reply to this post by ufomorace
Ok i have figured it out... here is an example of color per face cube file, just have to write in different arrays.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE X3D PUBLIC "http://www.web3d.org/specifications/x3d-3.3.dtd" "">
<X3D>
<Scene>
<Shape>

<IndexedFaceSet colorPerVertex='false' 
colorIndex='1 0 2 3 4 4' 
coordIndex='0 1 2 3 -1 7 6 5 4 -1 0 3 7 4 -1 0 4 5 1 -1 1 5 6 2 -1 2 6 7 3'>

<Coordinate point='
-0.095 -0.115 0.04
 0.095 -0.115 0.04
 0.095 0.115 0.04
 -0.095 0.115 0.04
 -0.095 -0.115 0.00
 0.095 -0.115 0.00
 0.095 0.115 0.00
 -0.095 0.115 0.00'/> 

<Color color='
0.999 0.0 0.0 
0.0 0.94 0.0
0.04 0.095 0.9115 
0.095 -0.85 0.00
0.04 0.095 0.00115 
'/>

</IndexedFaceSet>
</Shape> 


</Scene>
</X3D> 
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

ufomorace
Ok i have written an X3D color per face parsing code. It writes color X3D and i don't have the original colored vertex array from openscad so i can't color my model as originally intentioned... I have tried instead to color it by angle of the faces of the elements.

I just worked for 1 hour to understand why there is a difference in the angles of the normals of triangles that are at the same angle, what invisible mesh particularity is making my code bug slightly. So my coloration results are not practical for the moment, i would nearly prefer to code it directly into openSCAD for a solution. The x3d Export code i have coded was very straightforwards and saves the files fine every time. All that is missing is to compare the colors of the input mesh and write them to the output mesh.

1> i dont know what language OpenSCAD is written in
2> i dont know how private/static/reserved/next to window/void functions work
3> i don't know what variables to save the input array to, for later comparison to the output mesh, perhaps i should write it to a .txt file and read it after CGAL has finised writing, i dont know.
4> Perhaps someone could supply me with a coding framework for openscad where i have access to the input arrays of objects and their colors, and the output ones, and from there i can write a code that saves a color x3d file.


 icos colors some error

here is the x3d file i can save from an openscad .stl output:MATRICES24620.x3d
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

tp3
Von: ufomorace <[hidden email]>
> 1> i dont know what language OpenSCAD is written in
>
C++

> 2> i dont know how private/static/reserved/next to window/void
> functions work
>
I'd say that's not a huge issue, following the examples of
the other exports is quite good enough to get started.

Actually the whole export part needs some refinement as it
currently has some code duplication due to different internal
data structures.
(e.g. https://github.com/openscad/openscad/issues/910,
https://github.com/openscad/openscad/issues/909)

> 3> i don't know what variables to save the input array to,
> for later comparison to the output mesh, perhaps i should
> write it to a .txt file and read it after CGAL has finised
> writing, i dont know.
>
I don't understand that part. The current export code simply
writes data directly into a file output stream as it iterates
over the mesh.

See:
https://github.com/openscad/openscad/blob/master/src/export.cc

> 4> Perhaps someone could supply me with a coding framework
> for openscad where i have access to the input arrays of
> objects and their colors, and the output ones, and from there
> i can write a code that saves a color x3d file.
>
I'm not sure what coding framework means. Depending on which
Operating System you are working the process differs a bit.
On a recent Linux system, it's probably easiest to follow
the steps from the readme on GitHub as essentially all the
dependencies are available from the distributions.
For Windows, there's a description to set-up a MSYS2 based
development environment in the Manual.
(https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Building_on_Microsoft_Windows)
On MacOS, the dependencies are best compiled separately, I
think, but there are scripts to help with that.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

ufomorace
Thanks Torsten,

I can definitely add an x3d file format output because it is very similar to .amf output. It's trivial difficulty, if i add x3d to the switch(format) case list and i add a  export_x3d() function, i figure that x3d would appear in the window options list>file>export>format selection list. Perhaps no because it is also listed in another file?

So then there would be x3d export, without colors. then things become difficult.

So i have seen the cgal website for color, and there is some information about adding color using a class called Triangulation_vertex_base_with_info_3 , and there is an example here: http://doc.cgal.org/latest/Triangulation_3/#title12

And judging from the number of references to color on the cgal website, it's improbable that a color can be used from the input mesh.

Thanks for the advice for installing a dev environment, i will add x3d support and at least it will be there if someone knows about the triangulation_3 class or some other method for writing a color array.

If it were possible to have just the input mesh and the output mesh arrays i could arrange a color comparison code, and inside the output.cc wouldnt be a bad place to loop through both meshes and generate a new array for output colors that could be written to an x3d output file.  

I see std::ostream &output and root_geom variables, i can see that ostream somehow results in arrays , i think they arent computed live they are stored after the CGAL process... and the root_geom would be cool if it was the input geometry arrays, probably it isn'st.
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

tp3
Von: ufomorace <[hidden email]>
> i figure that x3d would appear in the /window options
> list>file>export>format selection list./ Perhaps no
> because it is also listed in another file?
>
The menu entry for the GUI would need to be added to the UI description
file (using the QtDesigner)
https://github.com/openscad/openscad/blob/master/src/MainWindow.ui

In case you don't want to dig into that, I guess it would be ok to
just add the part that's used from command line like for AMF:
https://github.com/openscad/openscad/blob/master/src/openscad.cc#L512
We can add the GUI part later.

> So then there would be x3d export, without colors. then things become
> difficult.
>
Yes, the color support will have to wait until the CSG engine
supports that.

> I see *std::ostream &output* and *root_geom* variables, i can see that
> ostream somehow results in arrays , i think they arent computed live they
> are stored after the CGAL process... and the root_geom would be cool if it
> was the input geometry arrays, probably it isn'st.
>
There's basically 2 cases of input objects for the export. If the
mesh generation went though CGAL, that produces the CGAL_Nef_polyhedron
(https://github.com/openscad/openscad/blob/master/src/export.cc#L333),
for some cases, e.g. just linear_extrude() of a 2d shape, the input
is a simple (and OpenSCAD specific) PolySet object
(https://github.com/openscad/openscad/blob/master/src/export.cc#L321).
Both contain the whole computed mesh which could contain more than
one volume.

AMF export is currently just lazy and converts PolySet objects also
to CGAL_Nef_polyhedron which is not ideal, but works for now.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

ufomorace
In reply to this post by ufomorace
I've found an hitch with this project. Netfabb basic is necessary to correct many complex STL's, and it doesn't support color. So if I arranged colors in openscad they would be erased when fixing the STL with netfabb, and most of us use basic version because consumer version costs 230.
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

jon_bondy
I rarely need to fix OpenSCAD STL files.  Perhaps you need to refine
your code?

On 10/17/2015 9:58 AM, ufomorace wrote:
> I've found an hitch with this project. Netfabb basic is necessary to correct
> many complex STL's, and it doesn't support color. So if I arranged colors in
> openscad they would be erased when fixing the STL with netfabb, and most of
> us use basic version because consumer version costs 230.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

tp3
In reply to this post by ufomorace
On 10/17/2015 03:58 PM, ufomorace wrote:
> I've found an hitch with this project. Netfabb basic is necessary to correct
> many complex STL's, and it doesn't support color. So if I arranged colors in
> openscad they would be erased when fixing the STL with netfabb, and most of
> us use basic version because consumer version costs 230.
>
There's no export format yet, where OpenSCAD supports colors (well, except
PNG, but I guess that does not count :-). So that's not much of an issue
yet.

At any rate, STL itself does not support any way of specifying colors,
so no program can support that without tricks like having multiple STL
files for different colors.

One option would be to use the newer AMF format which is supposed to
be STL 2.0. (they even use http://stl2.org/ as main web site).

ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Working around CGAL color limitations, mesh post processing.

ufomorace
In reply to this post by ufomorace
Sorry i meant encoding to a color .x3d. Some kinds of 3d i have errors, when alot of objects are union i get errors. Here is a color x3d made from an openscad file, It's from a random platonic weird algorythm, i thought it was very cool, unfortunately all the resulting random shapes are made of radial patterns which are aesthetically absurdist and mathematical and not human :\ I colored this in another program using color relative to the angles of the shapes. I am getting errors on most of these files stl files, then i fix them in netfabb and use unity3d to color them in and save as x3d files. It's viewable in meshlab.
PolyVTX__6409__13083.x3d