kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/3/2014 8:15 PM, Cirilo Bernardo wrote:
> On Sat, Oct 4, 2014 at 5:33 AM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx
> <mailto: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.

Cirilo,

Please don't fix anything just yet until I commit my changes.  Otherwise
we will have clashes in the code.  You may be correct about the x3d
files but I don't have any of them to test the code.  Looking at the
code, the output of the x3d to vrml conversion is being added to the
board vrml file not to a separate model file in the 3D model path which
is where I would expect it to go.  I also fixed a memory leak for every
x3d parser that is created.  If you happen to have an x3d model of a
component, please send it to me so I can test/fix this code path.

> 
>  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).

It makes sense to only have one copy of each unique model embedded in
the vrml file.  I'm guessing that each model definition in a vrml file
can be referenced more than once.  Until you have a chance to make the
changes to embed the models in the board vrml file, I will fix the
current code so it properly converts and copies x3d files to the 3D
model path.  I will also fix the 3D model file copying so it doesn't
overwrite the same model file for each time a model is used on the
board.  I'll probably use the source file modification time stamp and
only copy the file when the destination file doesn't exist or the
modification time has changed since the last copy.


> 
> 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.

Please keep the development team in the loop as you make progress.  It
might be a good idea to push a personal repo to launchpad so other
developers can test your code before we commit it to the product branch.

Thanks,

Wayne

> 
> 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
> 
>