ubuntu 7.10 GG, eclipse 3.3, cdt : trunk 38 compiles and starts but than crashes:
line 100: 31258 Segmentation fault (core dumped) $VARKON_BIN/xvarkon -GLOBAL -i$VARKON_INI/linux
is my system guilty? or is it the code?
trunk 37 is ok...
had some troubles to get it working on eclipse but perhaps because i'm learning eclipse too..
some quick tip how do i get to see perspective in oGL-window?
manipulating lights?
i'm professional a-class surface designer (icem surf): is anybody out there thinking about beziers? or should i try myself?
many thanks to Johan Kjellander & Co:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
#38 Works fine on our machines. It is important though
to always make clean before make when updating from
a previous trunk to a newer ie. from #37 to #38. It
seems that our makefiles do not cope with 100% of the
dependencies so...rebuild everything.
True perspective is not operational at the moment.
1.18 has perspective in OpenGL windows but 1.19 does
not have it. Hopefully it will be back in 2.0 Please
post a feature request about this. Same with lights
and material although these may come back earlier
than 2.0.
Beziers are available through the NURBS implementation.
Only in MBS though, no interactive support. Please
tell us more about your preferences for Beziers. How
do you use them, for what etc.
Johan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the true value of beziers (as i understand them!?) lays in relative easy intuitive geometric manipulation of single patches through their control points - which is perhaps for parametric application too much to ask?
i use beziers to build a-class automotive surfaces: car exterior/interior, accuracy from 0.2mm to 0.001mm depending on project (varkon with its 0.01 is not really in this league). to build a shape with this accuracy and to be able later to modify it (you always have to!) you have to analyze the form and build it with some geometrical logic applying to boundaries between neighboring entities. and entities you build with must be simple but flexible!!! hence beziers.
all implementations of nurbs that i know are very difficult to manipulate.
could you describe in general terms how model gets shown in oGL-window? the source is quite complex as you know and i don't know Swedish...
bohdan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
clean has worked, thanks!
will look at nurbs representation...
smallest settings/curve accuracy is 0.01. because it doesn't change anything visually (for circles anyway) i assumed it's real curve accuracy. was perhaps to hasty...
would really appreciate rough outline of oGL representation
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As Johan mentioned the implementation of NURBS can be used to also represent Bezier curves and surfaces, but there is for now no interactive interface for manipulation of NURBS/Bezier.
This is defenitely something that would be nice to add. We could then have a special mode for editing bezier control points as the convention for this is somewhat different from NURBS control point manipulation. Please add a feature request for "interactive NURBS/bezier creation and manipulation".
Regarding accuracy I do not know, but for me it seems strange that varkon accuracy shoud be 0.01 as default. My inpression is that Varkon is much more accurate. Somebody else that know, Johan, Gunnar?? From wher comes the value 0.01, the documentation or somewhere else?
Best regards
/Sören Larsson
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A good start on NURBS would be the MBS documentation on
CUR_NURBSARR() and SUR_NURBSARR().
settings/curve accuracy controls the graphical representation
of curves and surfaces on the display. It has no unit (inch/mm),
it's just a number between 0 and 100 and it has nothing at all
to do with the accuracy of the geometry. It's a purely graphical
thing.
The accuracy of the Varkon geometry is usually in the range of
at least 10 digits or more. For a surface 1 meter big this means
that you can calculate positions within the nanaometer ! I would
say that Varkon is more accurate than CAD systems in general.
Varkon is the only system I know of that has implemented analytical
representations of offset curves and surfaces for example. Other
systems use approximations.
To learn more about the Varkon graphics and how Varkon uses
OpenGL please have a look at the WP module in the sources.
Start with wpGlist.c and wpRWIN.c.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Accuracy: the representation of all coordinates in Varkon is double precision, so there is no limit of 0.01 on the achievable accuracy on input. This is really in the range of 18-19 significant digits iirc. The tolerance 0.01 if I understand it right is only used, when certain algorithms need to tell, if two points are identical to feed a heuristic. Problems may arise, if you try to construct features, that are smaller than 0.01 drawing units and relay on operations that need to tell, if two points are the same by a proximity test instead of connectivty information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ubuntu 7.10 GG, eclipse 3.3, cdt : trunk 38 compiles and starts but than crashes:
line 100: 31258 Segmentation fault (core dumped) $VARKON_BIN/xvarkon -GLOBAL -i$VARKON_INI/linux
is my system guilty? or is it the code?
trunk 37 is ok...
had some troubles to get it working on eclipse but perhaps because i'm learning eclipse too..
some quick tip how do i get to see perspective in oGL-window?
manipulating lights?
i'm professional a-class surface designer (icem surf): is anybody out there thinking about beziers? or should i try myself?
many thanks to Johan Kjellander & Co:
#38 Works fine on our machines. It is important though
to always make clean before make when updating from
a previous trunk to a newer ie. from #37 to #38. It
seems that our makefiles do not cope with 100% of the
dependencies so...rebuild everything.
True perspective is not operational at the moment.
1.18 has perspective in OpenGL windows but 1.19 does
not have it. Hopefully it will be back in 2.0 Please
post a feature request about this. Same with lights
and material although these may come back earlier
than 2.0.
Beziers are available through the NURBS implementation.
Only in MBS though, no interactive support. Please
tell us more about your preferences for Beziers. How
do you use them, for what etc.
Johan
what is your operating system?
the true value of beziers (as i understand them!?) lays in relative easy intuitive geometric manipulation of single patches through their control points - which is perhaps for parametric application too much to ask?
i use beziers to build a-class automotive surfaces: car exterior/interior, accuracy from 0.2mm to 0.001mm depending on project (varkon with its 0.01 is not really in this league). to build a shape with this accuracy and to be able later to modify it (you always have to!) you have to analyze the form and build it with some geometrical logic applying to boundaries between neighboring entities. and entities you build with must be simple but flexible!!! hence beziers.
all implementations of nurbs that i know are very difficult to manipulate.
could you describe in general terms how model gets shown in oGL-window? the source is quite complex as you know and i don't know Swedish...
bohdan
clean has worked, thanks!
will look at nurbs representation...
smallest settings/curve accuracy is 0.01. because it doesn't change anything visually (for circles anyway) i assumed it's real curve accuracy. was perhaps to hasty...
would really appreciate rough outline of oGL representation
Regardning bezier curves/surfaces.
As Johan mentioned the implementation of NURBS can be used to also represent Bezier curves and surfaces, but there is for now no interactive interface for manipulation of NURBS/Bezier.
This is defenitely something that would be nice to add. We could then have a special mode for editing bezier control points as the convention for this is somewhat different from NURBS control point manipulation. Please add a feature request for "interactive NURBS/bezier creation and manipulation".
Regarding accuracy I do not know, but for me it seems strange that varkon accuracy shoud be 0.01 as default. My inpression is that Varkon is much more accurate. Somebody else that know, Johan, Gunnar?? From wher comes the value 0.01, the documentation or somewhere else?
Best regards
/Sören Larsson
A good start on NURBS would be the MBS documentation on
CUR_NURBSARR() and SUR_NURBSARR().
settings/curve accuracy controls the graphical representation
of curves and surfaces on the display. It has no unit (inch/mm),
it's just a number between 0 and 100 and it has nothing at all
to do with the accuracy of the geometry. It's a purely graphical
thing.
The accuracy of the Varkon geometry is usually in the range of
at least 10 digits or more. For a surface 1 meter big this means
that you can calculate positions within the nanaometer ! I would
say that Varkon is more accurate than CAD systems in general.
Varkon is the only system I know of that has implemented analytical
representations of offset curves and surfaces for example. Other
systems use approximations.
To learn more about the Varkon graphics and how Varkon uses
OpenGL please have a look at the WP module in the sources.
Start with wpGlist.c and wpRWIN.c.
Accuracy: the representation of all coordinates in Varkon is double precision, so there is no limit of 0.01 on the achievable accuracy on input. This is really in the range of 18-19 significant digits iirc. The tolerance 0.01 if I understand it right is only used, when certain algorithms need to tell, if two points are identical to feed a heuristic. Problems may arise, if you try to construct features, that are smaller than 0.01 drawing units and relay on operations that need to tell, if two points are the same by a proximity test instead of connectivty information.