[x3d-public] file converter based on pythonocc

Andreas Plesch andreasplesch at gmail.com
Thu May 21 10:11:36 PDT 2020


Testing with another step model, a Kuka industrial robot, required deeper
parsing of the OCC loaded file(solid tshapes use tfaces which are also
subshapes). I also added optional edge accents, and edge geometry
conversion to the x3d generation:

https://nbviewer.jupyter.org/github/andreasplesch/OCCToX3D/blob/2c5bb3be92c1d88496c7ed4ab0779b4597ff9145/notebooks/doc_to_scenegraph.ipynb#

(wait and press 'a' in the x3dom output cell)

Here is a short summary of the three step to x3d export options now
available, for python:

OCC native vrml export: supports DEF/USE, supports colors, tends to
generate a lot of shapes, no accents, keeps transform hierarchy, needs
tox3dvrml, works with Kuka model

python-occ x3dom renderer: DEF/USE in development, supports color, tends to
generate a lot of shapes, supports accents, flattens hierarchy, uses
optionally inlines, has some problems with Kuka

doc_to_scenegraph: supports DEF/USE on various levels including appearance,
supports colors, less shapes, component DEF/USE=more performant, keeps
transform hierarchy, works with Kuka model, keeps names, extensible

I am thinking about TouchSensor based interactivity but this starts to be
application specific, probably just highlighting a component/solid/face on
isOver (by changing appearance of surface/accent). What would be useful in
the X3D to enable general X3D app. development ? Perhaps mostly just an
example of how to use the generated X3D.

x3d.py continues to be very convenient to use for generating x3d. One
problem is that it is sometimes desirable to use non-standard nodes and
fields which is doable after output to XML/VRML. Most X3D browser have some
of those. But then there is no way to read the XML back into a x3d.py
object, with a X3D.createX3DfromString function. So in the end, it is
tempting to just use strings in the first place, or an XML library such as
ElementTree.

Thanks for reading, any feedback welcome,

-Andreas

On Thu, May 14, 2020 at 7:03 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> It turns out that step can embed full unicode in these \X escape
> sequences, directives. So this has better naming and a bit specular:
>
>
> https://nbviewer.jupyter.org/github/andreasplesch/OCCToX3D/blob/3b05f7e4ff2777bdb2b08f5c487b714de2be4936/notebooks/rc_buggy_front_suspension.ipynb
>
>
> -Andreas
>
>
> On Thu, May 14, 2020 at 11:21 AM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> Using a more complex model surfaced a few bugs which are fixed here:
>>
>>
>> https://nbviewer.jupyter.org/github/andreasplesch/OCCToX3D/blob/e52f1372fb38294ceffa23e1bc57d29a4fd4bb92/notebooks/doc_to_scenegraph.ipynb
>>
>> With that a large model like this front suspension loads. It is 30MB so
>> it will take a bit:
>>
>>
>> https://nbviewer.jupyter.org/github/andreasplesch/OCCToX3D/blob/e52f1372fb38294ceffa23e1bc57d29a4fd4bb92/notebooks/frontsuspension.ipynb
>>
>> Press 'a' to zoom to all.
>>
>> Apparently, step files can contain strange naming of model parts. The
>> only choice is probably to preserve as they are.
>>
>> -Andreas
>>
>> On Wed, May 13, 2020 at 6:52 PM Andreas Plesch <andreasplesch at gmail.com>
>> wrote:
>>
>>> In order to avoid dependencies on external tools other than occ, and to
>>> allow for future enhancements such as better x3d naming, metadata or
>>> bounding boxes, we are working on a python only version.
>>>
>>> The notebook here adds DEF/USE and preservation of the OCC hierarchy in
>>> terms of a scenegraph:
>>>
>>>
>>> https://nbviewer.jupyter.org/github/andreasplesch/OCCToX3D/blob/5437c71b754b6d266a89796e552ac89e0978928b/notebooks/doc_to_scenegraph.ipynb
>>>
>>>
>>> There is a function which converts an occ document to a python data
>>> structure, a list of dictionaries, designed to be used for x3d purposes but
>>> potentially also for other scenegraphs. There is then a second function
>>> which tesselates and converts to x3d.
>>>
>>> The conversion is using x3d.py more extensively. It worked well. One
>>> observation is that a X3DfromString method for fields like MFVec3f could be
>>> quite useful.
>>>
>>> I will have to test the approach on a more complex assembly since I
>>> started to stray from just utilizing existing functionality.
>>>
>>> An update, -Andreas
>>>
>>>
>>> On Wed, May 6, 2020 at 5:39 PM Andreas Plesch <andreasplesch at gmail.com>
>>> wrote:
>>>
>>>> Here is a further update which adds edge accents through LineSets
>>>>
>>>>
>>>> https://nbviewer.jupyter.org/github/andreasplesch/OCCToX3D/blob/conda2/notebooks/doc_to_wire_vrml.ipynb
>>>>
>>>> Edges rendering is not natively supported by OCC but pythonocc has
>>>> extended functionality including edge rendering, meant for its x3dom
>>>> renderer.
>>>>
>>>> The x3dom renderer can be used to generate X3D but the example uses
>>>> the native OCC vrml export (it has more interesting def/use nodes) and
>>>> adds on the XML level the x3dom renderer edges.
>>>>
>>>> So this example uses now three sources for X3D: the OCC vrml export,
>>>> x3d.py, and pythonocc x3dom extensions, using XML as the glue.
>>>>
>>>> -Andreas
>>>>
>>>> On Wed, May 6, 2020 at 9:54 AM Andreas Plesch <andreasplesch at gmail.com>
>>>> wrote:
>>>> >
>>>> > We have been working on getting colors transferred to x3d as well.
>>>> Here is an example of a more complex assembly:
>>>> >
>>>> >
>>>> https://nbviewer.jupyter.org/github/andreasplesch/OCCToX3D/blob/conda2/notebooks/doc_to_vrml.ipynb
>>>> >
>>>> > This is also shows how to combine x3d.py generated X3D XML and
>>>> pythonocc generated vrml translated to x3d with tovrmlx3d, using python's
>>>> ElementTree builtin XML processing (which is basic but builtin).
>>>> >
>>>> > Just an update, -Andreas
>>>> >
>>>> > On Wed, Apr 22, 2020 at 7:22 AM Andreas Plesch <
>>>> andreasplesch at gmail.com> wrote:
>>>> >>
>>>> >> Just a quick update with a more complete notebook:
>>>> >>
>>>> >>
>>>> https://nbviewer.jupyter.org/github/andreasplesch/OCCToX3D/blob/77cda237a7055d796b48623712c0c0296d579973/notebooks/stp_to_x3d2.ipynb
>>>> >>
>>>> >> [scroll to the end]
>>>> >>
>>>> >> This demonstrates:
>>>> >>
>>>> >> - how to use pythonocc to load step files.
>>>> >> - how to use pythonocc to generate x3d, and vrml which uses a
>>>> different pathway.
>>>> >> - how to use view3dscene's tovrmlx3d from within python to convert
>>>> >> vrml to x3d xml.
>>>> >> - how to render x3d with x3dom in a python notebook [ note to the
>>>> >> future: since key presses get intercepted by the notebook, it would
>>>> be
>>>> >> useful to add js buttons to select viewpoints ]
>>>> >>
>>>> >> I also managed to use a more standard jupyter binder approach which
>>>> >> only uses conda on a regular ubuntu system. This should make the
>>>> >> notebooks easier to transport, and apply in regular python
>>>> >> environments.
>>>> >>
>>>> >> -Andreas
>>>> >>
>>>> >> On Sun, Apr 19, 2020 at 9:15 PM Andreas Plesch <
>>>> andreasplesch at gmail.com> wrote:
>>>> >> >
>>>> >> > Thanks for the response, see below for more.
>>>> >> >
>>>> >> > On Sun, Apr 19, 2020 at 7:29 PM Don Brutzman <brutzman at nps.edu>
>>>> wrote:
>>>> >> > >
>>>> >> > > cooler and cooler!
>>>> >> > >
>>>> >> > > On 4/19/2020 1:54 PM, Andreas Plesch wrote:
>>>> >> > > > I am happy to report that the core OCCT vrml writer works fine
>>>> with
>>>> >> > > > pythonocc. It generates more optimized vrml than the pythonocc
>>>> x3d
>>>> >> > > > exporter.
>>>> >> > >
>>>> >> > > obvious statement: if the vrml exporter works well, it might be
>>>> a simple variation to copy/refactor the output-producing sections of that
>>>> code to output XML instead of WRL.
>>>> >> > >
>>>> >> > > ... reading on ...
>>>> >> > >
>>>> >> > > > I updated https://github.com/andreasplesch/OCCToX3D with
>>>> example vrml
>>>> >> > > > output, and used tovrmlx3d to convert to xml which is also
>>>> available
>>>> >> > > > in the repo.
>>>> >> > >
>>>> >> > > very pretty outputs.  is it using LineProperties to give colored
>>>> borders along mesh edges?
>>>> >> >
>>>> >> > There is an option to generate wireframe output in addition to what
>>>> >> > they call shaded shape output. The edges are IndexedLineSets but
>>>> the
>>>> >> > Appearance does not have a LineProperties. This is something which
>>>> >> > x3d.py could presumably do in postprocessing.
>>>> >> >
>>>> >> > Another goal would be to add better Metadata since it should be
>>>> >> > possible to get those - probably prettyy easily - with pythonocc
>>>> from
>>>> >> > the original source.
>>>> >> >
>>>> >> > > > I could add tovrmlx3d to the docker image, and then call it
>>>> from
>>>> >> > > > python. Are there other options to convert from vrml2 to xml
>>>> x3d,
>>>> >> > > > using python ? x_ite could do it but requires a browser.
>>>> >> > >
>>>> >> > > i suspect that Holger knows how to run x_ite headless without a
>>>> browser.
>>>> >> >
>>>> >> > John went with headless chrome which is an option but it seems
>>>> heavier
>>>> >> > than using castle tovrmlx3d.
>>>> >> >
>>>> >> > >
>>>> >> > > > Enhancing c++ OCCT itself with a x3d writer, parallel to the
>>>> vrml
>>>> >> > > > writer is in principle possible but pretty daunting.
>>>> >> > >
>>>> >> > > this is what i was trying to express above... don't rewrite the
>>>> whole functionality, just look for output-producing code and put a selector
>>>> on those code blocks for one X3D encoding or another - .wrl for VRML97,
>>>> .x3dv for ClassicVRML (differs only in header line), then .x3d for XML.
>>>> >> >
>>>> >> > Yes but even with this strategy in mind it seems a major effort:
>>>> >> >
>>>> >> > mostly in:
>>>> >> >
>>>> http://git.dev.opencascade.org/gitweb/?p=occt.git;a=tree;f=src/Vrml;h=d24d7db215fb0c4f26ac73af52fe68735bf8adee;hb=master
>>>> >> >
>>>> >> > but also in:
>>>> >> >
>>>> http://git.dev.opencascade.org/gitweb/?p=occt.git;a=tree;f=src/VrmlAPI;h=bacc62597d161a9cb978386b13cb8ba8f072d6e4;hb=master
>>>> >> >
>>>> http://git.dev.opencascade.org/gitweb/?p=occt.git;a=tree;f=src/VrmlConverter;h=79507809ac27c8b4ed3674ede2c3198b06b352e1;hb=master\
>>>> >> >
>>>> http://git.dev.opencascade.org/gitweb/?p=occt.git;a=tree;f=src/VrmlData;h=18683ffff1dac6a17cd9eef9a3e37b25e642e50b;hb=master
>>>> >> >
>>>> >> > This would make x3d available to all OCCT users.
>>>> >> >
>>>> >> > Another option is to improve x3d generation by pythonocc:
>>>> >> >
>>>> >> >
>>>> https://github.com/tpaviot/pythonocc-core/blob/master/src/Display/WebGl/x3dom_renderer.py
>>>> >> > which uses
>>>> >> >
>>>> https://github.com/tpaviot/pythonocc-core/blob/master/src/Tesselator/ShapeTesselator.cpp#L427
>>>> >> >
>>>> >> > > > The pythonocc generated vrml and x3d does not include a nice
>>>> default
>>>> >> > > > viewpoint. If x3d.py would have a createX3DfromString()
>>>> method, it may
>>>> >> > > > be possible to add a viewpoint and then create xml with toXML.
>>>> >> > >
>>>> >> > > somebody with better python skills than me should write that
>>>> parser.  shouldn't be hard for a python guru since all of the X3D nodes
>>>> have Python classes with essentially the same name.
>>>> >> >
>>>> >> > Yes, I think that would make x3d.py a lot more useful. In addition
>>>> a
>>>> >> > createVRMLfromString() would help with legacy content, and
>>>> conversion.
>>>> >> > x_ite has good parsers in js which could serve as a template for
>>>> >> > python parsers. titanias parsers are probably similar.
>>>> >> >
>>>> >> > > > John suggested to use the stylesheet to convert from xml to
>>>> Python
>>>> >> > > > code. Saxon is probably the only processor which can handle the
>>>> >> > > > stylesheet ? There is saxon-c/he which is free and has
>>>> apparently a
>>>> >> > > > python wrapper:
>>>> https://www.saxonica.com/saxon-c/doc/html/saxonc.html
>>>> >> > >
>>>> >> > > I'm using Saxon Home Edition jar in all of the ant files for
>>>> builds and regression testing.  Also embedded in X3DJSAIL.  Even checked in
>>>> to help builders avoid versionitis.
>>>> >> > >
>>>> >> > > Better to find and use a Python package for XSLT 2 (not 1).
>>>> >> >
>>>> >> > Agree but there seem to be no native Python packages for XSLT 2.
>>>> The
>>>> >> > Python recommendation seems to be to use saxon he. In addition to
>>>> the
>>>> >> > java version, there is the c version which has an official Python
>>>> >> > wrapper. Do you want to give it a quick try ?
>>>> >> >
>>>> >> > > We would not want to hardwire such a package into x3d.py since
>>>> it might collide with other uses.  am trying to fit x3d.py well in the
>>>> python ecology.
>>>> >> > >
>>>> >> > > meanwhile I believe there is a python incantation to check at
>>>> run time and load such-and-such a package (if necessary) if a specialty
>>>> method gets invoked.  we might also create a x3d-tools.py package for
>>>> simplfying addition of commonly used packages (such as XSLT or even
>>>> pythonocc).
>>>> >> >
>>>> >> > pythonocc is big, since it depends on c++ occ.
>>>> >> >
>>>> >> > There is a pip package:
>>>> >> > https://pypi.org/project/pythonocc-core/#description
>>>> >> > but it has not been updated to 7.4.0, the current version.
>>>> >> >
>>>> >> > But there is also a conda package
>>>> >> > https://anaconda.org/pythonocc/pythonocc-core
>>>> >> > which is uptodate. Hm, I wonder why this is not used for the
>>>> binderhub
>>>> >> > pythonocc docker image. It is compiled from scratch in the
>>>> Dockerfile,
>>>> >> > instead. Perhaps the package does not work well.
>>>> >> >
>>>> >> > > > Did anybody try saxon-c/he with the python api ? It may work.
>>>> >> > > >
>>>> >> > > > If that is succesful, it would be probably possible to eval the
>>>> >> > > > resulting python code in python and get a x3d document/object.
>>>> This
>>>> >> > > > could then be manipulated with x3d.py.
>>>> >> > >
>>>> >> > > with enough coercion many things can be forced to work... but
>>>> cross-language solutions are notoriously difficult to port and maintain.
>>>> also worth noting is that 'eval()' opens up an endless security hole,
>>>> usually frowned upon...
>>>> >> >
>>>> >> > I do not think there would a lot of coercion sicne there is an
>>>> >> > official Python API for saxon.
>>>> >> >
>>>> >> > >
>>>> >> > > don't want to sound discouraging!  a build workflow can work
>>>> even if cross-language.  so those might establish initial capability, but
>>>> we are likely best served by seeking general Pythonic solutions when
>>>> possible/practical and then folding them into x3d.py itself.
>>>> >> >
>>>> >> > I agree, this should stay Python as much as possible.
>>>> >> >
>>>> >> > Cheers,  -Andreas
>>>> >> >
>>>> >> > > > So think the plan would be for now:
>>>> >> > > >
>>>> >> > > > - create a Dockerfile which includes also view3dscene for
>>>> tovrmlx3d
>>>> >> > > > - try Jupyter viola and/or appmode, there is an example with
>>>> upload of a file
>>>> >> > > > - use binder to host for now, get a viable service
>>>> >> > > > - try saxon-c/he python api, by installing in dockerfile and
>>>> then
>>>> >> > > > trying it in Jupyter.
>>>> >> > > >
>>>> >> > > > -Andreas
>>>> >> > >
>>>> >> > > good luck out there!  8)
>>>> >> > >
>>>> >> > >
>>>> >> > > > On Sun, Apr 19, 2020 at 12:35 PM Andreas Plesch <
>>>> andreasplesch at gmail.com> wrote:
>>>> >> > > >>
>>>> >> > > >> OpenCascade is the only realistic, open-source option to
>>>> digest step
>>>> >> > > >> format. It is a c++ library, so there is a need for
>>>> backend/server
>>>> >> > > >> side processing. The easiest option for that is docker and
>>>> there is a
>>>> >> > > >> preconfigured, working docker image with both, a working
>>>> OpenCascade
>>>> >> > > >> installation, and the pythonocc wrapper which also adds some
>>>> >> > > >> functionality such as x3d export. Also, python is faster to
>>>> iterate
>>>> >> > > >> than c++, and jupyter gets you even more convenience.
>>>> >> > > >>
>>>> >> > > >> I added a small example jupyter notebook which work on top of
>>>> >> > > >> https://mybinder.org/v2/gh/tpaviot/pythonocc-binderhub/master
>>>> to
>>>> >> > > >> https://github.com/andreasplesch/OCCToX3D, and an example x3d
>>>> >> > > >> conversion as proof of concept.
>>>> >> > > >>
>>>> >> > > >> I also discovered that OpenCascade supports generally
>>>> compilation to
>>>> >> > > >> wasm using emscripten. So longer term it may be possible to
>>>> compile
>>>> >> > > >> the OCC libraries required for loading, triangulation and
>>>> exporting
>>>> >> > > >> (to VRML) to wasm/ecmascript, and get a completely client
>>>> based
>>>> >> > > >> solution. However, the content typically is large and
>>>> complex, and
>>>> >> > > >> there is a lot of computation involved. So in practice it may
>>>> not work
>>>> >> > > >> out. A main advantage would be that users would not have to
>>>> trust a
>>>> >> > > >> remote server with their valuable content.
>>>> >> > > >>
>>>> >> > > >> I think next I will try for a bit if is feasible to use the
>>>> OCC VRML
>>>> >> > > >> writer, rather than the relatively simple pythonocc x3d
>>>> exporter. The
>>>> >> > > >> python wrapper seems to exist but I do not think there is an
>>>> example.
>>>> >> > > >>
>>>> >> > > >> -Andreas
>>>> >> > > >>
>>>> >> > > >> On Sat, Apr 18, 2020 at 9:47 PM John Carlson <
>>>> yottzumm at gmail.com> wrote:
>>>> >> > > >>>
>>>> >> > > >>> X3DJSAIL has
>>>> www.web3d.org/x3d/stylesheets/java/src/org/web3d/x3d/jsail/X3DLoaderDOM.java
>>>> which supports DOM scenegraphs.
>>>> >> > > >>>
>>>> >> > > >>> Examples of usage are here:
>>>> >> > > >>>
>>>> >> > > >>> www.web3d.org/x3d/stylesheets/java/nashorn/examples/Json.js
>>>> >> > > >>>
>>>> www.web3d.org/x3d/stylesheets/java/nashorn/examples/Nashorn.js
>>>> >> > > >>> www.web3d.org/x3d/stylesheets/java/nashorn/examples/X3d.js
>>>> >> > > >>>
>>>> >> > > >>> Basically, the examples parse JSON into a document using
>>>> X3DJSONLD.java then convert DOM into a X3DJSAIL scenegraph.
>>>> >> > > >>>
>>>> >> > > >>> So to answer your createX3DFromString() question, if you
>>>> start with JSON, I think you could get a X3DJSAIL scenegraph from a JSON
>>>> string using the X3DJSAIL-like python API (the one we got to work with
>>>> Jupyter).
>>>> >> > > >>>
>>>> >> > > >>> Otherwise, you probably have to wait for enhancements to
>>>> x3d.py.  It looks like toXML is supported in x3d.py currently.  One could
>>>> use a stylesheet X3dToPython.xslt to convert XML to Python.
>>>> >> > > >>>
>>>> >> > > >>> So one could use the stylesheet in a web program (GL with
>>>> that!) to output python.  Then you would have to use something like eval
>>>> (ugh!).
>>>> >> > > >>>
>>>> >> > > >>> John
>>>> >> > > >>>
>>>> >> > > >>>
>>>> >> > > >>>
>>>> >> > > >>>
>>>> >> > > >>> On Sat, Apr 18, 2020 at 5:20 PM Andreas Plesch <
>>>> andreasplesch at gmail.com> wrote:
>>>> >> > > >>>>
>>>> >> > > >>>> Thanks for the interest. I initialized a project at
>>>> >> > > >>>>
>>>> >> > > >>>> https://github.com/andreasplesch/OCCToX3D
>>>> >> > > >>>>
>>>> >> > > >>>> The wiki has some collected info and a short outline. The
>>>> wiki is
>>>> >> > > >>>> editable by anyone.
>>>> >> > > >>>>
>>>> >> > > >>>> pythonocc has a method to generate X3D xml. It is a simple
>>>> Shape with
>>>> >> > > >>>> a TriangleSet, nothing sophisticated. If x3d.py would have
>>>> a
>>>> >> > > >>>> createX3DFromString() function, it would be possible to use
>>>> x3d.py to
>>>> >> > > >>>> enhance the generated X3D. But I do not think x3d.py has
>>>> that. But
>>>> >> > > >>>> x3d.py may come in handy in other ways.
>>>> >> > > >>>>
>>>> >> > > >>>> The first goal is to add a simple jupyter notebook to the
>>>> repo based
>>>> >> > > >>>> on the available pythonocc docker image which demonstrate
>>>> how to load
>>>> >> > > >>>> step and output X3D.
>>>> >> > > >>>>
>>>> >> > > >>>> Any feedback or ideas welcome, using Issues on the project
>>>> or here,
>>>> >> > > >>>>
>>>> >> > > >>>> -Andreas
>>>> >> > > >>>>
>>>> >> > > >>>>
>>>> >> > > >>>>
>>>> >> > > >>>>
>>>> >> > > >>>> On Sat, Apr 18, 2020 at 1:27 PM Don Brutzman <
>>>> brutzman at nps.edu> wrote:
>>>> >> > > >>>>>
>>>> >> > > >>>>> Hi Andreas, sounds like a great idea to me.  Here are some
>>>> peripheral points of support.
>>>> >> > > >>>>>
>>>> >> > > >>>>> Last weekend i updated and deployed the x3d.py package
>>>> (sometimes called X3DPSAIL) at
>>>> >> > > >>>>>
>>>> >> > > >>>>> [1]     Python Package Index (PyPi) x3d 0.0.25
>>>> >> > > >>>>>          Package support for Extensible 3D (X3D) Graphics
>>>> International Standard (IS)
>>>> >> > > >>>>>          https://pypi.org/project/x3d/
>>>> >> > > >>>>>
>>>> >> > > >>>>> [2]     Python X3D Package x3d.py,X3D Python Scene Access
>>>> Interface Library (X3DPSAIL)
>>>> >> > > >>>>>
>>>> https://www.web3d.org/x3d/stylesheets/python/python.html
>>>> >> > > >>>>>
>>>> >> > > >>>>> "The x3d.py Python X3D Package supports programmers with
>>>> Python interfaces and objects for standards-based X3D programming, all as
>>>> open source.
>>>> >> > > >>>>> The presentation *Python X3D Package Implementation*
>>>> provides an overview and shows examples."
>>>> >> > > >>>>>
>>>> >> > > >>>>> [2.1]   Python X3D Package Implementation
>>>> >> > > >>>>>
>>>> https://www.web3d.org/x3d/stylesheets/python/documents/PythonX3dPackageImplementation.pdf
>>>> >> > > >>>>>
>>>> >> > > >>>>> So you would use this library for model creation and
>>>> data-driven improvement, no need to reinvent X3D data structures or methods.
>>>> >> > > >>>>>
>>>> >> > > >>>>> This is autogenerated from X3DUOM so it will always stay
>>>> in sync with latest/greatest X3D4.
>>>> >> > > >>>>>
>>>> >> > > >>>>> We've done some preliminary work with Jupyter notebook,
>>>> listed there.  Lots of potential projects in TODO section.
>>>> >> > > >>>>>
>>>> >> > > >>>>> [2.2]   X3DPSAIL: Jupyter notebook, TODO
>>>> >> > > >>>>>
>>>> https://www.web3d.org/x3d/stylesheets/python/python.html#Jupyter
>>>> >> > > >>>>>
>>>> https://www.web3d.org/x3d/stylesheets/python/python.html#TODO
>>>> >> > > >>>>>
>>>> >> > > >>>>> For pythonocc conversion efforts, will be happy to ensure
>>>> that
>>>> >> > > >>>>> a. all improvements to API are applied,
>>>> >> > > >>>>> b. ensure that validation of all scene-graph inputs
>>>> remains rigorous,
>>>> >> > > >>>>> b. utility methods are added for easy use together,
>>>> >> > > >>>>> d. examplar conversion models are properly saved in X3D
>>>> Examples Archive,
>>>> >> > > >>>>> e. Whatever else!
>>>> >> > > >>>>>
>>>> >> > > >>>>> Looks like there is vast potential here.  Hoping folks
>>>> start picking it up and applying capabilities.
>>>> >> > > >>>>>
>>>> >> > > >>>>> Have fun with X3D Python!  8)
>>>> >> > > >>>>>
>>>> >> > > >>>>>
>>>> >> > > >>>>> On 4/17/2020 5:15 PM, Andreas Plesch wrote:
>>>> >> > > >>>>>> Did somebody put together an x3d converter based on
>>>> pythonocc ?
>>>> >> > > >>>>>>
>>>> >> > > >>>>>> Here is an example:
>>>> >> > > >>>>>>
>>>> >> > > >>>>>> https://senties-martinelli.com/software/cad-viewer
>>>> >> > > >>>>>>
>>>> >> > > >>>>>> It could convert  step, stp, igs, iges, obj and stl
>>>> formats. Format
>>>> >> > > >>>>>> import and export is only a small subset of pythonocc
>>>> >> > > >>>>>> (https://github.com/tpaviot/pythonocc-core) but I think
>>>> just making
>>>> >> > > >>>>>> this functionality easy to use with a dedicated converter
>>>> could be
>>>> >> > > >>>>>> really valuable.
>>>> >> > > >>>>>>
>>>> >> > > >>>>>> In the end, I think a  web service just for conversion
>>>> would be most useful.
>>>> >> > > >>>>>>
>>>> >> > > >>>>>> I played with the Jupyter notebook and could generate
>>>> with only a few lines x3d.
>>>> >> > > >>>>>>
>>>> >> > > >>>>>> And there are ways to generate a standalone webapp from a
>>>> notebook:
>>>> >> > > >>>>>>
>>>> https://discourse.jupyter.org/t/how-to-transform-a-jupyter-notebook-into-a-webapp/758/6
>>>> >> > > >>>>>>
>>>> >> > > >>>>>> That could be quick way to offer a web service.
>>>> >> > > >>>>>>
>>>> >> > > >>>>>> Have there been attempts of this kind ? Would there be
>>>> interest in a
>>>> >> > > >>>>>> open source github hosted project ?
>>>> >> > > >>>>>>
>>>> >> > > >>>>>> -Andreas
>>>> >> > > >>>>>
>>>> >> > > >>>>> all the best, Don
>>>> >> > > >>>>> --
>>>> >> > > >>>>> Don Brutzman  Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>> >> > > >>>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>>>>  +1.831.656.2149
>>>> >> > > >>>>> X3D graphics, virtual worlds, navy robotics
>>>> http://faculty.nps.edu/brutzman
>>>> >> > > >>>>
>>>> >> > > >>>>
>>>> >> > > >>>>
>>>> >> > > >>>> --
>>>> >> > > >>>> Andreas Plesch
>>>> >> > > >>>> Waltham, MA 02453
>>>> >> > > >>>>
>>>> >> > > >>>> _______________________________________________
>>>> >> > > >>>> x3d-public mailing list
>>>> >> > > >>>> x3d-public at web3d.org
>>>> >> > > >>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>> >> > > >>
>>>> >> > > >>
>>>> >> > > >>
>>>> >> > > >> --
>>>> >> > > >> Andreas Plesch
>>>> >> > > >> Waltham, MA 02453
>>>> >> > > >
>>>> >> > > >
>>>> >> > > >
>>>> >> > > > --
>>>> >> > > > Andreas Plesch
>>>> >> > > > Waltham, MA 02453
>>>> >> > > >
>>>> >> > >
>>>> >> > > all the best, Don
>>>> >> > > --
>>>> >> > > Don Brutzman  Naval Postgraduate School, Code USW/Br
>>>> brutzman at nps.edu
>>>> >> > > Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>>>>  +1.831.656.2149
>>>> >> > > X3D graphics, virtual worlds, navy robotics
>>>> http://faculty.nps.edu/brutzman
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > --
>>>> >> > Andreas Plesch
>>>> >> > Waltham, MA 02453
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Andreas Plesch
>>>> >> Waltham, MA 02453
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Andreas Plesch
>>>> > Waltham, MA 02453
>>>>
>>>>
>>>>
>>>> --
>>>> Andreas Plesch
>>>> Waltham, MA 02453
>>>>
>>>
>>>
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>>
>>
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>


-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200521/fa0fbbf9/attachment-0001.html>


More information about the x3d-public mailing list