Hi Mario,
On Mon, Mar 30, 2015 at 10:55 AM, Mário Luzeiro <mrluze...@ua.pt> wrote:
> Hi Cirilo,
> see below:
> ________________________________________
> From: Cirilo Bernardo [cirilo.berna...@gmail.com]
> Sent: 29 March 2015 23:55
> To: Mário Luzeiro
> Cc: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] 3d-viewer future discussion
>
>
> [snip]
> > From my perspective what needs to happen to the 3D model component is
> for some
> > thought to go into how we handle different model formats and how we
> determine
> > what code module makes use of different types of 3D models.
>
> I didn't understand, is it related with 3d-viewer / VRML/X3D models?
>
>
To be able to introduce IDF models without changing the file format, some
small changes were made to 3DViewer so that it can select a VRML./X3D
or an IDF file; of course 3DViewer only cares about VRML/X3D and will
ignore IDF files. The structure holding an IDF file essentially only stores
the filename and the rotation/translation/etc parameters; at the moment
it never actually loads a model, but if someone wants it can always be
modified to load a model and create the point set for display. So the idea
was that there is this concept of a '3D model' - and it can be VRML/X3D,
IGES, STEP, or even a native MCAD format if anyone had a reason to
implement a native MCAD exporter. In reality I believe only IGES and STEP
will be added to the list.
One thing all 3D models share in common is the arbitrary (0,0,0) reference
and orientation. All 3D models also have the potential to create a point set
for rendering. A consumer of 3D models may also potentially mix models;
for example a STEP exporter might accept (and translate) IGES models.
The VRML exporter or 3DViewer may decide to render an IGES or STEP
model. There are many possibilities and I don't believe we should make the
design so rigid that these possibilities are excluded.
The most important point I have to make at the moment is that we can
continue to support an arbitrary number of 3D model types with no
change to the file format but we do need a coherent system for
registering the modules which can store extra parameters (currently
translation, scale, orientation) and model filename. If no one does this
I will eventually get around to it since it is needed by the IGES exporter
which I am working on, but if more people work on this feature I
certainly wouldn't complain.
One more thing is I believe we will eventually need at least some
small changes to the file format to improve usability of the 3D models,
but that use case is very minor in my opinion and can easily be
postponed for years. The changes I would suggest would be:
i. allow only 1 'scale' parameter for VRML models; since it is so easy
to generate nice models using tools like my 3D VRML parametric
modeler I see little value in reusing existing models by distorting their
dimensions, especially now that there are so many high quality models
available and when more people seem to be using VRML to obtain
more realistic images of the final product. The remaining 'scale' should
be used to scale the model to KiCad's 1U = 0.1inch model space.
ii. treat the X,Y,Z rotation and X,Y,Z offset as a set of parameters to
normalize the orientation and (0,0,0) reference of the model. Once
someone has worked out the parameters used for a specific model
then there is no need to change these values. Now there are times
when you want to add several models to a single component - for
example a ZIF socket + DIP. For that we will need a 'board offset'
parameter which is essentially a second Z offset. We will also need
to specify the units for the offsets; I would suggest only permitting
units of inch, mm, 0.1inch, and maybe mils; this way each user can
specify the offsets in whichever unit they are most comfortable with.
iii. to control the potential rendering of non-VRML/X3D models in
3Dviewer, add a 'visible' flag. Naturally such a flag may also be
used to suppress a VRML model from being displayed in the
3Dviewer.
>
>
> > In addition all models of course may have an arbitrary orientation and
> position
>
> If I understand correctly, we have it already now, that how they are added
> to the footprints..etc.
> As Wayne suggest, I miss a better management for this in Pcbnew, and, as
> in my idea, you can tune it in that management windows and see the result
> in real-time in the 3d-viewer!
>
>
That would be a very nice addition - perhaps a previewer with a mark at the
(0,0,0) position? If there is a 3D scale grid as well that would also help
determine
if the model scale is correct.
>
>
>
> > and in the case of VRML models even an arbitrary scaling. Handling the
> orientation is trivial but
> > how about the translation (offset)?
>
> The 3D viewer already supports it in the 3D Mesh/Models architecture, so,
> it will work for for VRML and X3D..etc
> Because you can make a tree of sub-modules, each model have his own
> transformation (offset, scale, orientation) and it will do it recursively.
> Most of the VRML models files have their data split in a tree of
> sub-triangles models.
>
>
If a single object can store the basic data for all instances and calculate
the point
sets for each instance I think this could be a huge improvement to the 3D
model
loading and rendering time.
>
> > What units do we use for the translation?
>
> The 3d-viewer only work with one unit... the 3DUnit :)
>
>
That's fine for the VRML/X3D models, but as I said before I think it's
best if VRML/X3D and other MCAD formats are all treated as a
logical item, the '3D model', rather than treating VRML/X3D as
a special case. As I said, there is even potential for actual
rendering of other model types so to me excluding this by
treating VRML/X3D as a special case would be a poor design
decision considering that nothing complex is required to treat
all 3D models of any type as a single class. The logical grouping
of 3D models is already done and is how IDF and VRML code
use the existing file format. Of course having an improved class
structure, rather than the current ad-hoc changes to accommodate
IDF, would make the code more manageable.
> In the footprint 3d module editor (footprint name, position, scale,
> rotation), position is in inchs. scale is a float, rotation is in angles.
>
> Internally, the VRML file is transformed to whatever the coordinates
> information it have. In the end, it is converted to the 3DUnit..
> Sorry if I am not explain in detail, anyway.. but what all it means is
> that "it render models in a relative size and position to PCB board mesh
> data" and.. thats why you cannot use this type of 3d-viewer to a proper
> mechanical evaluation. (3d-viewer deals with 3d triangle mesh models, not
> 3D CAD data)
>
>
>
>
> > The VRML models for example use 0.1inch = 1 unit but for IDF models what
> would we use and how do we ensure the correct translation on the PCB
> whatever
> > the selected output units is (mm/inch/mil). Any other MCAD model will
> share the same issue as the IDF models.
>
> Sorry I didn't understand it (the relation with IDF models and 3D viewer).
>
> I am not sure, but "0.1inch = 1 unit" was something that was defined by
> KiCad (and thats what is bases to make the transformations to display the
> models)
> If in the case a real CAD format would be used, the units used in that
> other formats.. shall be converted in a way that it have the same (visual)
> meaning and dimensions as the others..
> .. again.. thats why in the end nobody should use it for formal
> verification.
> or in the another way, if in any time, someone would like to make the
> 3d-viewer a trusted CAD viewer and real validation tool, much care must be
> taken with this subjects.. and of course.. VRML/X3D files will not be the
> proper file formats for that.
> It would be too much work and effort and thats why an external proper
> software should be used for that (using your future! IGES files :) )
>
>
>
>
> > So I imagine we need an API for specifying what type of model to load
> and what orientation/offset is required; this can be similar in many ways
> to the File IO plugin.
>
> I don't think we need anything much more fancy, considering 3d-viewer is
> not a CAD tool. VRML/X3D shall be the only formats for the visualization
> proposes..
>
>
>
>
> > Each model, whatever it is, must be the member of a base 3D model class.
> This
> > class will present other code modules with information about the type of
> model
> > it is storing - perhaps even a simple enum to let you know if the model
> is
> > VRML(1,2)/x3d(ascii, binary)/IGES/STEP/whatever.
>
> I believe you are thinking something different from me.
>
> By the way,right now, there is someway in the viewer that check the
> extension type of the model, so I believe other file formats can be added
> to the list of the footprint but they will not be processed.
>
>
Yes, this is due to changes introduced when I added the IDF export. Some
refactoring
to have a much cleaner structure/interface will really improve the code. In
the future
who knows - maybe someone will add the code so that IGES or STEP models can
also be displayed.
>
>
>
> > Another function should let you know if the object supports display of
> the model. For example the VRML/x3d
> > models all support display; the IDF models currently do not but it is
> not a big
> > job to create a representation for display. The IGES models will not
> create a
> > representation for display, but if someone had the time to implement one
> it
> > can certainly be done (though nowhere near as simple as displaying IDF).
> > But a future 3D viewer for example might have access to IDF and IGES
> modules
> > which will support display, so your 3D view can be a mix of models. Do we
> > even entertain such a thing or just say "no, only VRML/x3D shall ever be
> used
> > for 3D model display", in which case only the VRML/x3d modules will say
> that
> > they support display?
>
> If I understand it correctly, yes VRML/X3D support a scene definition that
> you can set camera position and so on (was that what you mean?)
> But, I think we don't need it, because we are render the model, not the
> scene it have embedded declared.
>
> 3d-viewer is (and shall be) basically a 3d triangle render engine. So, no
> matter which type of plugins / files import we have support, in the end..
> it must be just triangles!
>
>
No, I mean that in the current code only the VRML/X3D structures provide
data
needed for rendering, but that will not necessarily be the case in the
future. So
the questions are (a) how will 3DViewer know if it can display a
particular model
and (b) how will 3DViewer know if it *should* render that model. The
current list
of enumerated items which I initially added to provide IDF support will not
be
sufficient to decide what to render. We might also ask: how will the IDF
exporter
know if it can extract useful data from the 3DModel object? At the moment it
simply checks the to see if the object represents an IDF model, but it is
possible
to also use VRML data to determine a bounding box and produce an IDF model.
If we do not structure the code to allow for these possibilities in the
future then
people may not be able to provide such features without extensive
refactoring
again. So perhaps rather than the crude enum metthod which I added to
support IDF, we may need to use methods which return a string for the
supported input type and a list of supported output types (string) - a minor
nuisance at this stage and the string comparison will certainly add some
overhead
to the current 3D rendering but it may spare a lot of pain in the future as
people
decide to implement 3D model format translators and such.
>
>
> > One thing which many of us agreed should happen with the 3D model, and
> > VRML/x3d in particular, is that model data needs to be cached rather than
> > loading a model 1,000 times if there are 1000 instances of a component
> > and also to save time when reloading the board data and refreshing the
> > display.
>
> That (avoid multiple instances loading) was already implemented by me
> during this month.
>
> That is one of main things that I would have in mind: speed up .. i.e. for
> real-time change of the position of the footprints and update immediately
> in the 3d-viewer.
>
> Right now, the main consume time of loading is: generate the PCB board
> triangle mesh (with option remove the holes), (optional)calculate the
> smooth vertex and rendering all the triangle mesh data.
> The way the things are right now, it is very difficult / impossible to
> speed up whatever we want.. major changes would be needed... thats why I am
> bringing this discussion without first make any major change! :)
>
>
>
>
> > Another thing which would be nice is better support of the VRML
> > and x3d specifications, but I cannot imagine a good way to do this
> without
> > a major refactor.
>
> I spent this latest weeks almost just working on VRML2 parser issues. I
> believe it is now covering most of the VRML files sources (wings3d,
> FreeCad, etc..etc)
> Still there are some issues and bugs.
> Implement a full VRML will be very time consuming, so until now, I am
> following just the different cases we can found from the different sources
> (exporters). I found already some exporters that I believe are making
> incorrect VRML files.
>
>
>
>
> > In cases where there are no normals we would need to somehow create
> cache files of the normals.
>
> The regular normals are very fast to calculate. The smooth normals in huge
> models can take time. I think we discuss already something about the
> cache.. It may come again this discussion in the future.
>
>
>
>
> > What features would you want to add and how will they be useful?
>
> Related with my self and 3D, I am a guy from "3D entertainment" (gamedev,
> demoscene, 3D realist rendering...) so I like to "just look to it" and get
> amused :)
>
> When I start to contribute to this 3D-viewer, I was missing some "visual"
> validation of the PCB with the components / enclosure ("looking good"?
> "looking bad"?. I am not from CAD, so, for me just a quick visualization of
> the board and components will be fine.
> Then, I missed a good way to make 3D-renders of the board for "marketing
> proposes" (I dislike a lot some of the very old renders of KiCad that are
> spread in the web.. they look very primitive comparing to what the
> 3d-viewer render is today.. )
>
> So, that is OK now, we can load several VRML types of models and have a
> better looking rendering.
>
> What I special don't like it now is the time it takes to update/render any
> change..
> I miss some real-time interaction with Pcbnew (for adjust the component
> position and instantaneously see the result).
> I think it is useful for planning the design... testing positions of the
> components.. evaluate the on going results (as a second/ third way of view
> your board.. )
>
> I have in mind some other features after that, but it will be mainly
> render-eye-candy or fancy not so useful things that people will have fun
> and kill the productivity :P
>
>
>
That's great, I think we really need more people with expertise in the 3D
rendering
support; the code has been begging for some attention for some time now.
Even
providing a more universal support for VRML's 'DEF .. USE' constructs would
be a
great help; I could really shrink the size of many model files with
repetitive features
such as pins if I could make use of USE/DEF/TRANSFORM.
- Cirilo
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
