<div dir="auto">A render function that returns geometries would also be handy</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 3 Oct 2019, 10:53 Torsten Paul, <<a href="mailto:Torsten.Paul@gmx.de">Torsten.Paul@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03.10.19 15:08, shadowwynd wrote:<br>
>     name = "Fred";<br>
>     linear_extrude(2) text(name);<br>
<br>
Specifically this and also all the other imports are<br>
the most often asked candidates for querying geometry.<br>
The thing is those are the most easy ones that can live<br>
without as the data already exists and does not depend<br>
on calculated geometry.<br>
<br>
However to get the data out we need some more basic<br>
ground work to be done in the language that allows the<br>
data to be presented without ugly hacks that can never<br>
be fixed.<br>
<br>
I believe the changes to the parser that are currently<br>
in progress plus the "objects" proposal from Doug should<br>
allow import and text (and maybe others) to be used in<br>
a function context returning an object that has both<br>
the geometry as right now and also the additional raw<br>
data about the glyphs.<br>
<br>
While that is not a fully general solution, it should<br>
cover quite a number of use cases while still fitting<br>
into the OpenSCAD language without awkward and strange<br>
workarounds.<br>
<br>
If that all works out as I think remains to be seen<br>
and also depends on the time that can be dedicated to<br>
this.<br>
<br>
ciao,<br>
  Torsten.<br>
<br>
_______________________________________________<br>
OpenSCAD mailing list<br>
<a href="mailto:Discuss@lists.openscad.org" target="_blank" rel="noreferrer">Discuss@lists.openscad.org</a><br>
<a href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" rel="noreferrer noreferrer" target="_blank">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a><br>
</blockquote></div>