← Back to team overview

kicad-developers team mailing list archive

Re: VRML export.

 

On Sat, Oct 4, 2014 at 5:33 AM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
wrote:

> I've been trying use Pcbnew the VRML export for a board a work and
> discovered some serious design issues with the way file names are
> manipulated which broke exporting the model files on windows.  I fixed
> those and while digging around in the VRML export code, I noticed a few
> things that didn't make any sense to me.  Why are only .x3d file names
> embedded inside the board VRML file and not .wrl files?  Why are the
> .x3d file names embedded even when they are copied to the 3D model path?
>  Why wouldn't you either embed all the footprint models in the board
> file or copy all of the footprint model files to the 3D model path?  It
> seems to me it should be one or the other not both.  The use relative
> paths in the board VRML file option does nothing as far as I can tell.
> I'm willing to fix this but we need to define what this behavior should
> be because what we have now is rather chaotic.  My initial feeling is
> that the embedded code should be removed until we can embed all
> supported 3D model file formats.  Anyone else have any thoughts on this?
>
> One more note.  Please use wxFileName instead of wxString when
> manipulating file names and paths.  I've probably fixed a dozen or so
> places over the years where this same wxString path manipulation code
> has been used and has caused nothing but grief.  Please keep in mind
> that we are a cross platform application.  If you need Posix path
> separators for saving paths and/or file name in files, use
> wxFileName::GetFullPath(wxPATH_UNIX).  This will convert the separators
> from \ to / and still allow you to use native paths for file operations
> internally which is more reliable.
>
> Thanks,
>
> Wayne
>

Hi Wayne,

 I'll find some time to have a look at the issues.  I don't get what you
mean
by the x3d file names being embedded and not the wrl files. I always thought
it was the other way around. The X3D model data is written to the output
VRML file but the VRML data is retained as separate files and only the names
are put into the output VRML file. Embedding the X3D model date assures
VRML2 compatibility; a VRML2 browser will not necessarily be able to
parse and display the contents of an x3d file. I didn't realize the x3d
models
were being copied to the path as well; that's just wrong.

 Before I rewrote much of the VRML exporter,  it always used file
references to
the models, never the actual model data. It is the introduction of the X3D
code
which changed this a bit. What I'd like to do is to put all the VRML model
data in a single file as well, but this is not a simple task. For me, the
ideal is to create a model management object which implements caching
and other tricks to minimize the memory footprint. These object models
should be able to export data in VRML2 format as the X3D code currently
does (though admittedly in a very inefficient way). I'd also like the output
to use DEF/USE to keep the file as small as possible.  It's all possible;
the IDF tool 'idf2vrml' can create VRML files which reuse objects and it
also has an option not to reuse objects so that the output can in turn be
used an an input model to KiCad.  Of course if we improved the VRML loader
for KiCad so that it handled DEF/USE better that would simplify some things
and allow many detailed models to be more compact (for example we don't
have hundreds of 1206 models, or 64 pin models on each TQFP64).

So changes are planned, but at the moment they're on hold pending the
ongoing work on the VRML model caching for 3DViewer. I'll assess the size
of the task when appropriate, but the STEP work has a much higher
priority for me.

I'll keep wxFileName in mind for file name manipulation. I've probably used
strings in my IDF tools as well.  I'll make a note to check the code.

- Cirilo

Follow ups

References