Chi Ng (Apr 19 2019 at 20:32): Chi Ng (Apr 19 2019 at 20:32):where is the best place to report BRL-cad bug. Tried sending to: brlcad-devel@lists.sourceforge.net, but email was rejected.
Daniel Rossberg (Apr 20 2019 at 11:56):@Chi Ng Are you subscribed to this list? https://sourceforge.net/projects/brlcad/lists/brlcad-devel
Our official bug tracker is https://sourceforge.net/p/brlcad/bugs. You need a Sourceforge account to create a ticket there.
You can however post your bug report here too.
Sean (Apr 20 2019 at 15:11):@Chi Ng Your reports were received to the devs@ address, thank you. At a glance, they are rather involved, complicated, and I'm not sure how much Windows 7 is having an influence. We're no longer doing testing and development on 7, so hopefully only the datetime issue is limited to that version issue.
Chi Ng (Apr 20 2019 at 16:01):@Daniel Rossberg @Sean Thank you all for your reply. No worry about Windows 7. I did replace GetSystemTimePreciseAsFileTime with GetSystemTimeAsFileTime to get my system to run on Windows 7. If precise timing is required for the importers, indeed it would be my system. I will upgrade to Windows 8 and give it run again. By the way, the 3dm-g importer is quite impressive. Some none trivial models I converted to . g database are private so couldn't show publicly, but they look really amazing on archer.
Chetan Shinde (May 15 2019 at 10:02):
The bug number not getting printed with label is occurring because of this reason.
The issue is occurring because of line no 79
so the issue is as the flag sets to 1 further loop gets skipped and hence the size of the letters which is to be printed cannot be calculated and hence..no cannot be created. like for example... try typing a single 1, it wont print, but try typing eight 1's these 1's get printed as the area required to print them is of certain size.
A quick fix to it is commenting line 79.
Sean (May 15 2019 at 11:57):@Chetan Shinde I'm not familiar with this particular logic - what is disp_mode supposedly used for? there's undoubtedly some reason that it's turned on for BN_VLIST_DISPLAY_MAT ... another solution just from a data perspective might be to set disp_mode to 0 elsewhere but you'd have to more completely understand what's going on in that function.
Sean (May 15 2019 at 11:59):at a glance, there clearly seems to be switch settings in two groups -- those that directly cause something to be displayed / drawn (below the attribute comment) and those that do not (above the comment), with that disp_mode possibly keeping track of which. if unsetting it for line drawing somehow helps, that implies that logic is awry or logic elsewhere is wrong.
Chetan Shinde (May 15 2019 at 12:47):@Shubham Rathore can you please help us to understand why the disp_mode flag was added to, the code.
thanks.!
Daniel Rossberg (May 15 2019 at 13:42):The coordinates in the vlist can be given in the model or display coordinate system, i.e. points in the model space (same as for the geometric primitives) or points on the display window (similar to the texts and lines of mged's face plate). The MODEL_MAT and DISPLAY_MAT flags switches between these two spaces.
Daniel Rossberg (May 15 2019 at 14:37):The DISPLAY_MAT flag is followed by a 3D point, which determines the origin of the display coordinate system in the world. Whenever you display an annotation, you display it on the screen in screen coordinates, this means, "10 mm" are 10 mm on the screen. The (0, 0) point of this coordinate system is always where the 3D point following the DISPLAY_MAT flag would be displayed as a world coordinate on the screen. This way, you can always see the labels clearly when you move or zoom your model.
And, it's correct that the annotation lines and texts are ignored for the computation of the bounding box, as they don't "live" in the world. The only world point there is the 3D point following the DISPLAY_MAT flag. An annotation will be displayed when this point is visible, otherwise not.
Last updated: Jan 09 2025 at 00:46 UTC