Daniel Rossberg (Mar 19 2019 at 08:59): Daniel Rossberg (Mar 19 2019 at 08:59):@Chetan Shinde (switching to a more appropriate stream)
The final commit to the X Window display manager (src/libdm/dm-X.c) which made it working was the one for revision 70165. I would expect the same thing to work with the TK display manager. If it's so, it would be a nice patch to prove once coding abilities.
Chetan Shinde (Mar 19 2019 at 09:26):Chetan Shinde (switching to a more appropriate stream)
The final commit to the X Window display manager (src/libdm/dm-X.c) which made it working was the one for revision 70165. I would expect the same thing to work with the TK display manager. If it's so, it would be a nice patch to prove once coding abilities.
Can you please share the link to the last commit to the X window display manager. It would help a lot.
Daniel Rossberg (Mar 19 2019 at 09:56):Use Subversion for displaying the logs of dm-X.c. You should make yourself familiar with it. There are nice file manager plugins which provide GUIs too.
On Sourceforge: https://sourceforge.net/p/brlcad/code/72663/log/?path=/brlcad/trunk/src/libdm/dm-X.c
Chetan Shinde (Mar 19 2019 at 16:07):You can create it by yourself, e.g. as a cylinder: https://brlcad.org/wiki/BRL-CAD_Primitives#rcc
You can find example geometries in the directory, where your BRL-CAD installation is, under share/db.
In general, I recommend to go through the BRL-CAD tutorial (https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf), at least the first chapters, to become familiar with mged.
As suggested by Daniel i have gone through the wiki page and the first chapter of mged as well,along with that i also tried to google the error but no results were found and still, I am still facing the error " rt_db_external5_to_internal5(annot_test): unable to import non-BRL-CAD object, major = 225 minor = 42 rt_db_get_internal(annot_test) failure" How can i resolve this error so that i can understand the annot module created by @Shubham Rathore
Chetan Shinde (Mar 19 2019 at 16:34):You can create it by yourself, e.g. as a cylinder: https://brlcad.org/wiki/BRL-CAD_Primitives#rcc
You can find example geometries in the directory, where your BRL-CAD installation is, under share/db.
In general, I recommend to go through the BRL-CAD tutorial (https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf), at least the first chapters, to become familiar with mged.As suggested by Daniel i have gone through the wiki page and the first chapter of mged as well,along with that i also tried to google the error but no results were found and still, I am still facing the error " rt_db_external5_to_internal5(annot_test): unable to import non-BRL-CAD object, major = 225 minor = 42 rt_db_get_internal(annot_test) failure" How can i resolve this error so that i can understand the annot module created by Shubham Rathore
The screenshot might help in understanding better the context of this error.
Daniel Rossberg (Mar 19 2019 at 19:57):I can reproduce this issue. The version from some weeks before doesn't has it. It will need some time to identify the cause.
Sean (Mar 19 2019 at 22:40):@Chetan Shinde this is why getting annotations into a finished usable statue would be a good project. ;) What's there was working for a few limited cases, but there aren't any regression tests so it's easy for what was working to stop working. Also, it simply wasn't finished even for basic labels as labels need to display in the 3D world or alternatively in the 2D display, and need to work at different positions and scalings. From my understanding and observations, there were a few bugs that need to be resolved too.
Chetan Shinde (Mar 21 2019 at 17:45):@Sean @Daniel Rossberg While going through the code i came across some bu_logs which print certain string given if the project is running into debug mode can you tell me how to start the project in debug mode.
Chetan Shinde (Mar 21 2019 at 18:14):@Sean Daniel Rossberg While going through the code i came across some bu_logs which print certain string given if the project is running into debug mode can you tell me how to start the project in debug mode.
Hey thanks got it.. http://brlcad.org/~maths22/HACKING_BRL-CAD.pdf thanks for the book @Sean :)
Chetan Shinde (Mar 21 2019 at 18:15):@Sean Daniel Rossberg While going through the code i came across some bu_logs which print certain string given if the project is running into debug mode can you tell me how to start the project in debug mode.
Hey thanks got it.. http://brlcad.org/~maths22/HACKING_BRL-CAD.pdf thanks for the book Sean :)
page no 31 helps you to configure the project into debug mode.
Chetan Shinde (Mar 22 2019 at 09:57):I can reproduce this issue. The version from some weeks before doesn't has it. It will need some time to identify the cause.
Was the issue identified @Daniel Rossberg ?
Daniel Rossberg (Mar 22 2019 at 19:50):Not yet. I have the idea that there could be something wrong with the memory allocation and cause a write behind the allocated area and corrupting the major value.
Sean (Mar 23 2019 at 03:14):@Chetan Shinde you're welcome! any feedback on the book is appreciated.
Sean (Mar 23 2019 at 03:20):@Sean Daniel Rossberg While going through the code i came across some bu_logs which print certain string given if the project is running into debug mode can you tell me how to start the project in debug mode.
@Chetan Shinde for most applications that support it, there are debug command line switches like -x -X and -! ... not all applications support them, but most of the complex ones do. For mged/archer, there are different embedded commands you can run on their individual command prompts (e.g., the "debugbu" command)
Shubham Rathore (Mar 23 2019 at 14:46):Not yet. I have the idea that there could be something wrong with the memory allocation and cause a write behind the allocated area and corrupting the major value.
Oh yes ! Its getting set to "-1" in the export function and ending up with "255" in external->internal in db5_io somehow. Still need to find the exact point where its getting corrupted !
Daniel Rossberg (Mar 23 2019 at 14:50):@Chetan Shinde I found the cause of the error. But, I don't know why it ever worked.
Maybe you can find the cause by yourself, es an exercise in debugging BRL-CAD: Run mged in a debugger of your choice and investigate the ged_in() (in src/libged/typein.c) function there. This function is the entry point of the in command. Create several primitives in mged with in and look especially for the major and minor values from the error message while debugging this function: How are the different <primitive name>_in() functions setting them, and why annot_in() has an issue there?
Daniel Rossberg (Mar 23 2019 at 14:51):Not yet. I have the idea that there could be something wrong with the memory allocation and cause a write behind the allocated area and corrupting the major value.
Oh yes ! Its getting set to "-1" in the export function and ending up with "255" in external->internal in db5_io somehow. Still need to find the exact point where its getting corrupted !
Unfortunately, it looks like this wasn't one of my best guesses.
Chetan Shinde (Mar 24 2019 at 04:03):Not yet. I have the idea that there could be something wrong with the memory allocation and cause a write behind the allocated area and corrupting the major value.
Oh yes ! Its getting set to "-1" in the export function and ending up with "255" in external->internal in db5_io somehow. Still need to find the exact point where its getting corrupted !
This is mostly happening because of the directory structure defined in brlcad-svn-trunk/include/rt/directory.h , this structure is used for representing each named object in the database. In this structure the d_major_type and d_minor_type are defined as unsigned char , as the major and minor are getting set to -1 in the export function because of been assigned as unsigned the value is changing to 255 from -1.
Shubham Rathore (Mar 24 2019 at 07:46):Chetan Shinde I found the cause of the error. But, I don't know why it ever worked.
Found it ! Its works now. No idea why it was previously working.
@Chetan Shinde Try looking at the annot_in() in typein.c w.r.t the major_type variable setting. Should be an easy catch now !
Shubham Rathore (Mar 24 2019 at 07:50):This is mostly happening because of the directory structure defined in brlcad-svn-trunk/include/rt/directory.h , this structure is used for representing each named object in the database. In this structure the d_major_type and d_minor_type are defined as unsigned char , as the major and minor are getting set to -1 in the export function because of been assigned as unsigned the value is changing to 255 from -1.
Well it doesn't seem to go this way. You could investigate better by putting in some bu_logs in the export functions and comparing the major_type with the DB5_MAJORTYPE_BRLCAD. Not initializing a variable usually results in some gibberish values !
Chetan Shinde (Mar 24 2019 at 09:17):This is mostly happening because of the directory structure defined in brlcad-svn-trunk/include/rt/directory.h , this structure is used for representing each named object in the database. In this structure the d_major_type and d_minor_type are defined as unsigned char , as the major and minor are getting set to -1 in the export function because of been assigned as unsigned the value is changing to 255 from -1.
Well it doesn't seem to go this way. You could investigate better by putting in some bu_logs in the export functions and comparing the major_type with the DB5_MAJORTYPE_BRLCAD. Not initializing a variable usually results in some gibberish values !
Hey thanks! @Shubham Rathore and @Sean , @Daniel Rossberg
Should i create a pull request for the change ?
Shubham Rathore (Mar 24 2019 at 10:12):Yea, go ahead submit a patch (commit rights are restricted as of now :P).
Chetan Shinde (Mar 24 2019 at 12:42):While compiling the project i came across this warning
Screenshot-from-2019-03-24-18-06-51.png
The warning will go away by initializing the __n long variable. Should i ignore it or carry out the change?
Chetan Shinde (Mar 25 2019 at 04:31):Was trying to checkout other available primitives similar issue was found with hrt.
Hrt-prblem.png
Tried to fix this bug as well by the previous approach, now getting insufficient memory allocation.
Sean (Mar 25 2019 at 04:46):While compiling the project i came across this warning
Screenshot-from-2019-03-24-18-06-51.png
The warning will go away by initializing the __n long variable. Should i ignore it or carry out the change?
That is a warning in a system header.
Sean (Mar 25 2019 at 04:46):You should not change system headers.
Sean (Mar 25 2019 at 04:47):If you can find what code is calling into that header, you might be able to quiet the warning in a better way.
Chetan Shinde (Mar 25 2019 at 04:48):While compiling the project i came across this warning
Screenshot-from-2019-03-24-18-06-51.png
The warning will go away by initializing the __n long variable. Should i ignore it or carry out the change?
That is a warning in a system header.
Yea, that's the reason i thought of asking before breaking anything :) Thanks @Sean !
Sean (Mar 25 2019 at 04:48):The insufficient memory allocation bug would be a perfect one to debug and submit a patch for. If you know how to use a debugger like gdb or lldb, they can help you pinpoint the issue in just a couple minutes.
Chetan Shinde (Mar 25 2019 at 04:50):The insufficient memory allocation bug would be a perfect one to debug and submit a patch for. If you know how to use a debugger like gdb or lldb, they can help you pinpoint the issue in just a couple minutes.
Yes I have used gdb a couple of times will work on it. (Will seek help if needed).
Daniel Rossberg (Mar 25 2019 at 19:41):Should i create a pull request for the change ?
@Chetan Shinde How is the creation of the patch going?
Chetan Shinde (Mar 27 2019 at 03:41):Should i create a pull request for the change ?
Chetan Shinde How is the creation of the patch going?
Have made that changes locally, regarding the annotation bug and was thinking of submitting patch for both the hrt and annotation bug together initially, but as i am not done with hrt bug yet, atleast i will upload patch for annotation bug by today it self.
As this is my first patch I guess i am expected follow instructions from this page. https://brlcad.org/wiki/Patches ?
Sean (Mar 27 2019 at 03:59):@Chetan Shinde yes, those are the typical steps for making a patch file.
Sean (Mar 27 2019 at 04:00):also, please do not combine them even if you do complete hrt. patches should be separated for each logical change. this makes them easier to review, modify, and/or apply.
Chetan Shinde (Mar 27 2019 at 11:44):also, please do not combine them even if you do complete hrt. patches should be separated for each logical change. this makes them easier to review, modify, and/or apply.
https://sourceforge.net/p/brlcad/patches/521/ I have created the patch.
Chetan Shinde (Mar 27 2019 at 12:02):also, please do not combine them even if you do complete hrt. patches should be separated for each logical change. this makes them easier to review, modify, and/or apply.
https://sourceforge.net/p/brlcad/patches/521/ I have created the patch.
While creating the patch I was asked about Owner of the ticket which i am generating.. does that mean the person who should address that ticket or is there any more relevant meaning behind that option? Just asking our of curiosity :)
Chetan Shinde (Mar 27 2019 at 12:05):The same fix is working for hrt as well. :)
hrt_pic.png
Chetan Shinde (Mar 27 2019 at 12:13):The same fix is working for hrt as well. :)
hrt_pic.png
Now the new patch file which i have made is having both the changes now i am suppose to edit the new patch file and upload only the current changes made right?
Sean (Mar 27 2019 at 13:54):That looks good @Chetan Shinde ! Owner is just who it's assigned to -- ideally anyone who you've been working with on this that could commit it for you. One of us will take a look at the patch ASAP regardless, but can you explain what the bug was?
Sean (Mar 27 2019 at 13:56):Since this is a thread about annotations, here's a few relevant images I came across that are good examples of where we want to get to:
tolerance-drawing-box.gif images.jpeg 3d-authority-model.jpg
Sean (Mar 27 2019 at 13:57):The last one is particularly good example because it shows a variety of annotations on the geometry as well as view-aligned annotations (the notes / text up in the top-left).
Chetan Shinde (Mar 27 2019 at 14:41):That looks good Chetan Shinde ! Owner is just who it's assigned to -- ideally anyone who you've been working with on this that could commit it for you. One of us will take a look at the patch ASAP regardless, but can you explain what the bug was?
Before answering this question can I ask a question regarding the brlcad repository.
On the brlcad wiki there are two links to clone latest repository.
1. svn checkout svn://svn.code.sf.net/p/brlcad/code/brlcad/trunk brlcad-svn-trunk
(I had initially downloaded the project from the above link)
(the above mentioned link is on this wiki page https://brlcad.org/wiki/Compiling and states that to download latest repository which are not to be runned on a virtual machine, but i guess it is pointing to the repo which is to be meant to run on virtual machine).
As i had initially tried many changes to the code base to fix the hrt problem, I was not able to create a clean patch file for the first issue.
so, I noted down the changes made for the first patch and deleted the whole project and downloaded it from the second link.
2. svn checkout https://svn.code.sf.net/p/brlcad/code/brlcad/trunk brlcad
(This link is on this wiki page https://brlcad.org/wiki/Patches ) , I carried out changes which were need for the first patch and created a ticket for it.
Then again i went back to the hrt issue. Initially again i tried to create hrt which gave the same error of major-value not initiallised, then i solved that issue and again tried to create a new hrt and this time it work.
the function was not working for link 1 as the "slides" was randomly getting initialised to -2,147,483,647, i tried to follow the trail but was not able to figure out why initially it was getting assigned (the variable "slides" of rt_ell function) to -2,147,483,647 and now it was not.
If a wild guess is allowed, what i can say that is as initially (still assuming) as i had download the repository from a link which is ment to run on a virtual machine, i was getting a segmentation fault as i was not running it on a virtual machine and now with the proper link i was just able to fix hrt as well as i did it for annot.
If this above made assumption is correct we need to state that link mentioned on this wiki https://brlcad.org/wiki/Compiling is ment for running brlcad on virtual machine.
I guess, the reply turned to be to long, but will help us to get the complete picture.
Chetan Shinde (Mar 27 2019 at 14:54):That looks good Chetan Shinde ! Owner is just who it's assigned to -- ideally anyone who you've been working with on this that could commit it for you. One of us will take a look at the patch ASAP regardless, but can you explain what the bug was?
I have created second ticket as well https://sourceforge.net/p/brlcad/patches/522/ please review it if it is done correctly.
Chetan Shinde (Mar 27 2019 at 14:58):Since this is a thread about annotations, here's a few relevant images I came across that are good examples of where we want to get to:
tolerance-drawing-box.gif images.jpeg 3d-authority-model.jpg
Regarding the proposal I had shortlised few annotations which can be considered for this gsoc considering the limited time we are having, will try to complete my proposal in day or 2 and will submit it for review :)
Chetan Shinde (Mar 29 2019 at 04:38):
in the annotation primitive structure for the pointer *reverse is used, (was not able to get it from the comment written beside it.)
Shubham Rathore (Mar 29 2019 at 17:00):@Chetan Shinde regarding the patch, you had to remove the extra whitespaces in the blank line rather than removing the line itself ( The blank line above "intern->idb_major_type = DB5_MAJORTYPE_BRLCAD;" had some spaces). Go through the indentation routines or either have a look at the other primitive functions.
P.S. : you may also go through the sh/ws.sh and sh/indent.sh. ;)
Louis Googl (Mar 29 2019 at 20:58):hello , my name is ali I am a civil engineer I have experience in C++ and graphics using directx i would like to participate in this project but i don't know if my skills is enough to this project. I have read the patch of 2017 project for annotations is it weird that I didn't under stand what the magic.h do ? . and for understanding the layout of the code can you provide me with specific references talks about the namespace and defined data types ?
Sean (Mar 29 2019 at 21:27):@Chetan Shinde I'm not sure either, but I'd guess that it describes which direction the annotation is to be traversed. for example, you might have a segment going from 0,0,0 left to -1,0,0 then up to 1,0,1 making an "L" shape from the bottom up. If the reversed flags were set on those two segments, it'd make an L shape from the top-down. Difference being more obvious when you put a label at the end of the last point, either at the top of the L or on the bottom-right.
Sean (Mar 29 2019 at 21:29):@Louis Googl welcome! if you have experience with c++ and directx, you shouldn't have too much trouble with a variety of projects, but it just depends how much experience you have
Sean (Mar 29 2019 at 21:31):magic.h is simply a manual way of adding a "type" integer onto the beginning of a structure. that way, if memory ever gets corrupted for any reason, the magic number will change, code that checks the magic number can detect that it's not right, and stop the program instead of letting it try to work on corrupted memory.
Louis Googl (Mar 30 2019 at 21:36):thank you my problem is how to recognizes each header file purpose is there any specific documentations for that ?
Sean (Apr 01 2019 at 14:28):@Chetan Shinde please keep discussions public, and thank you for your proposal submission! it looks pretty good though I would make a few suggestions. first, I think you actually need to reduce the scope a little bit. before introducing new concepts like balloons and dimensions, basic labeling need to be completely demonstrated, debugged, and working well for both view-aligned and world-aligned annotations. I refer you again to that last image pasted above which has both types displayed together. second, I'd like to see a week-to-week timeline in your proposal that includes what work would be completed during the bonding period and what you'd intend to be working on each of the coding weeks. included in that plan should be time for testing, debugging, documentation, etc, (but not just at the very end) while still being mostly writing code.
Chetan Shinde (Apr 01 2019 at 17:24):Chetan Shinde please keep discussions public, and thank you for your proposal submission! it looks pretty good though I would make a few suggestions. first, I think you actually need to reduce the scope a little bit. before introducing new concepts like balloons and dimensions, basic labeling need to be completely demonstrated, debugged, and working well for both view-aligned and world-aligned annotations. I refer you again to that last image pasted above which has both types displayed together. second, I'd like to see a week-to-week timeline in your proposal that includes what work would be completed during the bonding period and what you'd intend to be working on each of the coding weeks. included in that plan should be time for testing, debugging, documentation, etc, (but not just at the very end) while still being mostly writing code.
Sure! I have uploaded the proposal on gsoc site as suggested by @Shubham Rathore , will help to gather input from the whole brlcad organisation. Second, will keep balloons in future possible work domain.
Second, Can you please elaborate on the second point basic labelling ....
Third, "Last Image pasted above" (assuming we are taking about Unilateral Tolerance.) in this type of tolerance either the upper limit or the lower limit is set to 0 i.e it is defining that variation in that direction is not allowed example, referring the image into consideration from 0.375
variation upto 0.875 is allowed but 0.374 that is 0.001 less value is not allowed.
and the limit tolerance type is another way of representation, the dimension's range is represented instead of representing the base measurement and tolerance. example ( 0.775 +- 0.500 ) can be represented as (1.275, 0.275).
Fourth, will come up with a more detailed timeline.
Sean (Apr 01 2019 at 19:42):By basic labeling, I mean making sure even simple labels area working correctly with the position, lines, and text drawn in the right way for both view-aligned and world-aligned labels, for objects not at the origin, objects with scales applied, objects rotated, and combinations thereof. Last I tested, most of those were not working right and view-aligned wasn't implemented at all.
Sean (Apr 01 2019 at 19:45):Tolerances are also something not of immediate concern -- I'd suggest those be deferred until later when dimensions are implemented. What is implied by 3d-authority-model.jpg is having world-aligned and view-aligned labels.
Chetan Shinde (Apr 01 2019 at 19:57):Tolerances are also something not of immediate concern -- I'd suggest those be deferred until later when dimensions are implemented. What is implied by 3d-authority-model.jpg is having world-aligned and view-aligned labels.
Can you please tell me about the BRL-CAD coordinate system and in which files I can find the logic for it. this will help me in restructuring my proposal. info about the tcl rendering will be an add-on.
Sean (Apr 01 2019 at 20:44):this is best described at https://brlcad.org/wiki/Documentation in various documents like the intro mged, principles of effective modeling, and the quick ref card
Sean (Apr 01 2019 at 20:47):the logic for it very much depends on exactly what you're doing, it's nearly everywhere in a sense. better would be to follow an example that does similar things to what you're needing to do, like seeing the drawing code when a primitive is edited
Sean (Apr 01 2019 at 20:49):a good example might be to follow what the Sketch object does: https://brlcad.org/wiki/Sketch
the code for drawing wireframes starts in src/libged/draw.c and eventually calls into src/librt/primitives/* (e.g. sketch/sketch.c)
Daniel Rossberg (Apr 02 2019 at 10:17):Understanding the different coordinate systems is crucial for this project. The world coordinate system is the coordinate system of the main group. This is usually the coordinate system i which you add the primitives. E.g., when you put in a sphere, the center and radius are meant as a point and dimension in the world. I said usually because these values can be altered by transformations given in the compinations.
However, the annotation primitive lives at a different coordinate system: The screen or paper system. I.e., if an annotation text shall be 5mm heigh, this means 5mm on the screnn or on the paper, when printed out.
Knowing how to do this is annother essential part of the project. I highly recommend to provide a patch which makes the current annot primitive work on OpelGL windows to get selected.
And, if you complete the implementation of the annot primitive in the GSoC project, multi-line annotations should work automatically.
Louis Googl (Apr 02 2019 at 19:35):a good example might be to follow what the Sketch object does: https://brlcad.org/wiki/Sketch
the code for drawing wireframes starts in src/libged/draw.c and eventually calls into src/librt/primitives/* (e.g. sketch/sketch.c)
that is what I meant by my question how to draw the annotation after constructing it in the code.
this is very helpful
is there a code example of drawing just a line segment ?
and does the program support drawing fonts or we should construct the letters using line segments ?
thank you
Louis Googl (Apr 02 2019 at 22:55):for drawing a line I found vdraw.c .
Sean (Apr 03 2019 at 03:28):@Louis Googl the details are for you to discover, but there is lots of code examples that add to the wireframe, both lines and letters via a built-in font. for understanding that, you'll want to search the codebase on related keywords like RT_ADD_VLIST and BN_VLIST_POLY_MOVE or simply all occurrences of "grep -r -i vlist ."
Shubham Rathore (Apr 03 2019 at 15:51):@Chetan Shinde There is an extra line in your patch.
Shubham Rathore (Apr 04 2019 at 14:14):Sure! I have uploaded the proposal on gsoc site as suggested by Shubham Rathore , will help to gather input from the whole brlcad organisation. Second, will keep balloons in future possible work domain.
@Chetan Shinde . Regarding the proposal, your first aim should be to fix all the bugs that the annot primitive currently encounters, before you move on to dimensions and tolerances. Moreover single and multi line notes aren't different things. As Daniel said, there needs to be proper understanding about the coordinate systems. SCALING of the annotations is another thing that needs attention.
It will be good if you keep the scope limited, rather than promising things that wont end up in time. I feel focusing on a limited scope and demonstrating the approach to be taken in detail would look better. There are a number of extension ideas for example, support for an annotation editing command that enables users to edit the properties of the annotations, but again these will only be useful if we have a bug free structure for the annot.
Louis Googl (Apr 04 2019 at 16:55):pasted image
pasted image
I am still struggling with under standing the code but i have a small idea like encapsulate vlist functions inside the annotations that we can make an editable shape for each annotations like the image above I know It is not very advanced but it can take advantage of the resizing and transformations built in the environment ? ( this a statement and a question :grinning: )
Chetan Shinde (Apr 04 2019 at 17:43):Sure! I have uploaded the proposal on gsoc site as suggested by Shubham Rathore , will help to gather input from the whole brlcad organisation. Second, will keep balloons in future possible work domain.
Chetan Shinde . Regarding the proposal, your first aim should be to fix all the bugs that the annot primitive currently encounters, before you move on to dimensions and tolerances. Moreover single and multi line notes aren't different things. As Daniel said, there needs to be proper understanding about the coordinate systems. SCALING of the annotations is another thing that needs attention.
It will be good if you keep the scope limited, rather than promising things that wont end up in time. I feel focusing on a limited scope and demonstrating the approach to be taken in detail would look better. There are a number of extension ideas for example, support for an annotation editing command that enables users to edit the properties of the annotations, but again these will only be useful if we have a bug free structure for the annot.
Yes, I am working towards limiting the scope of the project so, that some realistic contribution can be made to the period in gsoc timeframe.
Sean (Apr 05 2019 at 02:55):I am still struggling with under standing the code but i have a small idea like encapsulate vlist functions inside the annotations that we can make an editable shape for each annotations like the image above I know It is not very advanced but it can take advantage of the resizing and transformations built in the environment ? ( this a statement and a question :grinning: )
@Louis Googl that sounds quite reasonable for dimension-style and symbolic annotations like in the examples that were pasted, but it cannot be emphasized enough that the focus does need to be on proving that simple text labels are working perfectly. If you read the BUGS file, there is an example of one of the current annotation bugs -- see if you can reproduce the bad behavior. You'll also want to read the TOD file as there's a significant section on annotations in there that are some of the foundations for what is needed.
Louis Googl (Apr 10 2019 at 08:11):you mean the bug page on the sourceforg websit or there is a bug file some where ? can you provide some links ? thank you
Sean (Apr 10 2019 at 15:39):@Louis Googl no, you need to get a checkout of the repository from subversion, and there you will find a file named BUGS and TODO
Daniel Rossberg (Apr 20 2019 at 16:55):@Louis Googl and everybody else interested in the annotation topic:
Since this is a thread about annotations, here's a few relevant images I came across that are good examples of where we want to get to:
tolerance-drawing-box.gif images.jpeg 3d-authority-model.jpg
These images aren't wrong but give a wrong impression about how annotations shall look like in BRL-CAD. With their symbols, they are obviously conform with a standard, but it's hard to believe that this standard allows skewness or arbitrary letter size. These images only make sense with one or more paper planes for blueprints with associated scales behind.
As "paper plane" and "scale" are usual entities in a CAD, there are no adequate objects in BRL-CAD for expressing them. That's why for the first implementation of annotations in BRL-CAD the natural paper plane and scale was chosen: The current display plane and scale.
I.e., the annotations size shall be its size on the screen. The annotation shall always be displayed at the same size and front-on on the screen. Unfortunately, this doesn't work with OpenGL and therefore on Windows yet. I would expect that displaying annotations had to work somehow similar to displaying the faceplate in mged with OpenGL.
Sean (Apr 20 2019 at 17:16):I tend think of it not so much as which plane they are drawn or skew as it is a screen space vs world space perspective. We're focused on screen space for now, and obviously eventually want to get to annotations in world space, but not until screen space is fully fleshed out and working right.
The standards those images conform with are ASME Y14.5 2009, which is more about what the boxes mean and should contain, not how they are presented in a 3D view. For simplicity, most CAD systems I've seen let the user specify annotations on either the XY plane, YZ plane, XZ plane, or aligned to the view. Some allow arbitrary user-defined planes too.
Sean (Apr 20 2019 at 17:20):Where it can imply a usability difference is that one doesn't usually need to be concerned with z-depth when working in screen space. Everything is a projected 2d coordinate. So you could, for example, draw a label in the 0,0 bottom left (assuming 1st quadrant coordinate system) corner of the screen with the name of the object and a leader line pointing towards the object. Alternatively, I might define a 3-space coordinate at 123.0, 234.0, 345.0 that we can project into the screen space plane, and that might end up in the bottom left, but that is quite a different input and handling.
Sean (Apr 20 2019 at 17:22):Maybe it'd be worthwhile to draw up a picture of the 3 styles in question. The point wasn't to be misleading, but to increase awareness that there are different types and it would be good to be aware of their differences as there are usability and design implications.
Sean (Apr 20 2019 at 17:25):To oversimplify, say we had a label command that created annotations. It's the difference between:
label 0,0 "some string in the bottom left, always in view"
and
label 0,0,0 "some string at the origin, maybe or maybe not in view"
Daniel Rossberg (Apr 21 2019 at 13:04):Introducing the concept of "paper" and "scale" in BRL-CAD isn't complicated, I think. At least the database representation should work with the existing objects. There nothing new had to be programmed. The depiction requires some work/programming. But, maybe, with a new GUI, it could even feel natural to have this.
Louis Googl (Apr 21 2019 at 23:42):@Daniel Rossberg thank you I will try to thhink in this way . I have fixed the patch of leader line.
Chetan Shinde (Apr 22 2019 at 18:45):@Sean @Daniel Rossberg @Shubham Rathore Hello, everyone. Just got done with my practical examinations :). In the mean time along with studying for my examination, managed to solve the no numerical label issue in brlcad :)
(from Bugs file)
in ann3.s annot 0 0 0 1 10 10 3 1
# using numbers for a label results in no label
(Bug reproduced) Reason-for-1-not-printing.png
(Solved the bug.)
Solved-The-bug-.png
(Printing decimal values as well)
Priting-complex-decimal-value.png
(This bug help me to understand the code's flow and get a complete inside of the annotation module.) #great experience :)
Chetan Shinde (Apr 22 2019 at 18:53):As i had mentioned this bug solving in my proposal, now i can utilized that allocated time, to work on adding some other required feature for the annotation module :grinning:
Chetan Shinde (Apr 22 2019 at 18:56):Introducing the concept of "paper" and "scale" in BRL-CAD isn't complicated, I think. At least the database representation should work with the existing objects. There nothing new had to be programmed. The depiction requires some work/programming. But, maybe, with a new GUI, it could even feel natural to have this.
Thanks @Daniel Rossberg Will work further in this direction. :+1:
Sean (May 05 2019 at 03:59):Came across a relevant screenshot I'd stashed related to annotations: fig11-B_1.png draftproannotations.jpg
Louis Googl (May 06 2019 at 23:16):I am very happy that I was selected , thank you very much for you help , @Sean @Daniel Rossberg , I hope I will be a good choice and I will do me best.
Louis Googl (May 08 2019 at 10:59):they said we should start bonding now @Daniel Rossberg @Sean @Shubham Rathore , my name is louis I have two brothers and two sisters :grinning: :heart: , I want to ask what should I do next and if we will keep contacting here or in the IRC or in some where else ? thank you very much .
Shubham Rathore (May 08 2019 at 11:14):First of all please add your project description to http://brlcad.org/wiki/Google_Summer_of_Code/2019 , there is a pre-existing template there to help you out. You may take reference from the previous year wiki https://brlcad.org/wiki/Google_Summer_of_Code/2018 .
Secondly, upload the abstract and your proposal to the wiki.
Finally, you must have a platform for your daily logs, you may use the wiki or any other platform for this. Make sure you update it regularly even in the community bonding period (you should mention the content that you coded up or went through in that day). This will serve as an update for us and we will be able to analyze the direction in which the project is going.
P.S. - You may upload a more refined proposal than you submitted previously.
Daniel Rossberg (May 08 2019 at 17:59):@Louis Googl Thirsty for action? Good!
In addition to what Shubham said, you should have a Linux handy. Your main development environment is Visual Studio on MS Windows(?). This is OK, but Linux serves often as a reference/primary system for BRL-CAD. Especially for the annotations, their representation on X Window is currently the reference. I.e. you should have a Linux installed, for example in a virtual machine or dual boot, and make BRL-CAD compile there.
Louis Googl (May 08 2019 at 20:19):@Shubham Rathore thank you , I have read some parts of your blog on the 2017 project can I do one like it ? or its better to make one on the wiki ? , I was thinking about refining the proposal before adding it on the wiki.
Louis Googl (May 08 2019 at 20:27):@Daniel Rossberg actually I am exited and a little bit scared of the evaluation :sweat_smile: , so I wanted to start as early as possible , yes i usually use Visual studio but my first build of the code was on Linux using virtual box but it takes too much time to compile and several tries, it took 21:00 hours , do I have to do all the work using Linux or maybe write the code and then check if it works on Linux ?. thank you.
Daniel Rossberg (May 09 2019 at 17:44):You don't have to be scared of the evaluations. In the many years BRL-CAD took part in GSoC we had also to fail some students there, but this were cases when something really went wrong, and we will communicate in advance if we see a problem there.
You can use Visual Studio as your main development environment. I used it as mine for many years too. But you should have Linux for checks an as reference handy.
Is your computer slow in general or VirtualBox only? If the latter applies, you should check if the virtualization support is enabled in your BIOS.
Louis Googl (May 09 2019 at 20:21):@Daniel Rossberg I will do my best ,I am going to dual boot my machine , it is not slow usually the build on Vs takes 20 minutes .
do you have some suggestions to refine the proposal before adding it to the wiki ?
Louis Googl (May 09 2019 at 22:14):like organizing the Ideas and seeing which of them is applicable in the frame of the project .
Sean (May 10 2019 at 15:26):@Louis Googl You'll be getting an e-mail shortly with additional details, but congratulations on getting selected for GSoC -- I'm very much excited for your project and glad to see you getting started right away. For the bonding period, I encourage you to ask as many questions as possible, read the code, get your development environment set up, and maybe try a few of the mged tutorials. That will give you some basic that help with understanding how to create, visualize, and edit annotation objects.
For what it's worth, you can do all your development on Windows but just realize that you may end up needing to fix things there as several of the other devs don't like doing that as frequently as it's required, myself included. If you have trouble getting Linux set up, let me know and we can get you an account set up on another system.
As for what specifically you need to do in the bonding period, there's a nice checklist for you at https://brlcad.org/wiki/Summer_of_Code/Checklist
Daniel Rossberg (May 11 2019 at 13:34):@Louis Googl At first, you should fix the issues in the current implementation. This includes the wrong depiction with OpenGL, for example on Windows.
Next, you would need to extend the data structure by references. When you want to display symbols and texts side by side, you need a way to say something like "from the right border of the segment with id xxx go 2 mm to the right and then display this segment there".
When you are able to do this, very much of what's in https://www.3dcadworld.com/leveraging-3d-cad-data/ can be seen could be done. What't would be missing for the full functionality are references to the BRL-CAD database elements for the dimension lines and a notation for display planes ("paper"), which I would implement as a flag in the combinations, similar to the regions.
Louis Googl (May 13 2019 at 12:37):@Sean thank you I hope I can be as good as required , I installed Ubuntu in dual boot is there any specific IDE and debugger you advice? , I have also a problem with the Payoneer account they rejected my application they said due to limitations imposed on U.S companies and they asked for more documents. I know this is not the place to ask about that but I know you have experiences with students from last years.
Louis Googl (May 13 2019 at 13:03):@Daniel Rossberg you are the hardest Mr. Daniel :grinning: .is there any references to understand the wrong depiction with OpenGL ? thank you .
Sean (May 13 2019 at 14:08):@Louis Googl if you're looking for a graphical IDE, you might want to try Eclipse, NetBeans, or Atom. Personally, I use Emacs. As for debugger, you're going to want to use either gdb or lldb depending on whether you're using the gcc or clang compiler.
As for Payoneer issues, I don't have any advice. I suggest reading what they sent you in detail and submit the additional documentation.
Daniel Rossberg (May 13 2019 at 17:55):As you are coming from Windows I recommend to have a look at KDevelop. Because you already know Visual Studio, you should get used to it. There is a KDevelop back-end in CMake, but I recommend to let KDevelop create the project files from the CMake configuration.
Daniel Rossberg (May 13 2019 at 18:12):Daniel Rossberg you are the hardest Mr. Daniel :grinning: .is there any references to understand the wrong depiction with OpenGL ? thank you .
Why isn't it reasonable to correctly depict the annotations with OpenGL too ;)
You can see the correct depiction of annotation with the X Window display manager on Linux.
The annotation, as it's currently implemented, is defined in screen screen coordinates in mm. I.e., a test with height 5 should always be 5 mm height on the screen, independently from the zoom and rotation of the model. In this sense, it should behave similar to the face plate in mged. The routines which depict this face plate could be a reference for how this can be achieved.
And the good part is, that OpenGL is used for the draw routines on Windows. You can develop it with Visual Studio there.
Louis Googl (May 17 2019 at 01:11):@Daniel Rossberg @Sean @Shubham Rathore I have installed ubuntu and build the code successfully, I think we should discuss the proposal before uploading it on the wiki ? tell me you opinions about the goals and if you think some things could not be implemented in the time of the project .
Louis Googl (May 17 2019 at 01:17):As you are coming from Windows I recommend to have a look at KDevelop. Because you already know Visual Studio, you should get used to it. There is a KDevelop back-end in CMake, but I recommend to let KDevelop create the project files from the CMake configuration.
I used KDevelop
Shubham Rathore (May 17 2019 at 06:36):First of all please complete the checklist items as said by Sean previously. I couldn't find your project details on the wiki. It's high time now, that you complete these tasks and move over to the code base. Regarding your proposal, I couldn't find a well defined timeline in the proposal that you uploaded. Primarily come with a timeline and then we should be able to improvise.
Daniel Rossberg (May 17 2019 at 12:29):First, you should eliminate the shortfalls of the current annotations. I.e. fix the bugs, enlarge the mged (and archer) commands to input arbitrary annotations (as they are currently possible), ....
Then, introduce a feature like referring other segments inside an annotation. This is needed for the creation of boxes, underlines, putting texts and symbols side by side, etc.. For example, when you want to draw a box around a text, the line segments need to know the length and height of this text, but how?
Louis Googl (May 17 2019 at 21:41):@Shubham Rathore I am sorry for being late but i was trying to under stand the X window depiction(faild :grinning: )and struggling with payoneer live chat , starting with the check list the first item says I have to agree on the acceptance requirements in writing , where I have to write that I agree ? for the proposal i am working on it , what do we mean by milestones? for submitting batches can you give me feed back about the two bugs that I suggested a solution for 1- the debug assertion error 2- annotation points at origin? and I will try to solve some more.
Sean (May 17 2019 at 22:07):where I have to write that I agree ?
You send me an e-mail.
for the proposal i am working on it , what do we mean by milestones?
Check out some of the previous year GSoC proposals (they are ALL on our wiki) for examples, but basically you need to have a general notion of what you plan to be doing for each week of the coding period and when you think major tasks will be completed.
Louis Googl (May 17 2019 at 22:58):pasted image
but I am living in Italy they are not reading my emails !!!!!
Louis Googl (May 18 2019 at 02:24):pasted image problem solved she said that I can continue my project .
Daniel Rossberg (May 18 2019 at 16:51):Shubham Rathore I am sorry for being late but i was trying to under stand the X window depiction(faild :grinning: )and struggling with payoneer live chat , starting with the check list the first item says I have to agree on the acceptance requirements in writing , where I have to write that I agree ? for the proposal i am working on it , what do we mean by milestones? for submitting batches can you give me feed back about the two bugs that I suggested a solution for 1- the debug assertion error 2- annotation points at origin? and I will try to solve some more.
Louis Googl (May 18 2019 at 17:43):This is how it looks at my computer: Screenshot_20190413_180624.png
Revision 72903 (version 7.30.3) on Linux (Debian 9).Daniel Rossberg Sean I found the error causing the first bug in the bug file where the annotation appear to be pointing to (0 , 0 , 0) and I made a fix it works but I have another tow Ideas for the fix pasted image
the cause of the error is in seg_to_vlist()
pasted image
when trying to send the annotated point to the list pasted image
we can see that annot_ip->verts[lsg->end] is not a point or is not initialized correctly and it didn't contain the coordinates of the annotated point so me fix is to save the coordinates of the annotated points in a point and pass it to the list
pasted image
pasted image
so the error may be in annot-ip->verts . the second Idea is fix verts to be verts[1] contains the annotated point.
the third Idea is when you go to wgl_drawVlist() the annotated point is the first point in the list but with a cmd=15 which I don't know what it means but even if we fix it from here the third point in the list pt[2] will always be (0,0,0) because of the annot_ip->verts[1] error . I hope you give me feed back thank you very much .
@Daniel Rossberg this is what i did with annotation appear to point to (0,0,0)
Louis Googl (May 18 2019 at 17:46):pasted image
it all existed in #general build channel
Louis Googl (May 18 2019 at 21:49):* What's the matter with the X Window depiction? Window display manager is correct. I.e., it's an OpenGL issue. You should really start to look into OpenGL :wink:
the matter with x window is I am new to Linux and you told me that the right depiction is in X window but I don't know where to find the code written for it so i can have an idea abut the right solution to make like it in OpenGl .
Louis Googl (May 18 2019 at 21:50):can you mention some code example to see ?
Daniel Rossberg (May 19 2019 at 16:17):@Louis Googl
Annotation points at origin error: OK, still a bunch of screen shots only. In case we shall review your code, you have to provide us with a patch file, for example at https://sourceforge.net/p/brlcad/patches/. With your comments in #general I should be able to understand it.
X Window display manager: Start mged with the "-c" option mged -c.
Daniel Rossberg (May 19 2019 at 16:23):... and select "X" then.
Louis Googl (May 20 2019 at 20:17):@Sean I want to ask you if there where a channel on zulip for the 2017 annotations project and if i can find it some where ?
Sean (May 20 2019 at 20:22):We were not using Zulip back in 2017. We do also have an IRC channel running and were more actively using it back then, so you could search our IRC archives, but it's a slow search process: http://infobot.rikers.org/%23brlcad/
Louis Googl (May 21 2019 at 01:32):this is extended description of the project on the wiki , I am sorry for being late its because our university is taking us to Poland will be back on 23th . https://brlcad.org/wiki/User:Ali_Haydar/GSOC19/project
I hope you give me feed back and I hope I will finish the time table tomorrow.
Thank you.
Sean (May 21 2019 at 02:06):@Louis Googl Thank you, that's looking like a good start. The checklist deadline is mostly to help make sure everyone is prepared and not procrastinating to the last minute (or worse). It's important to get all the prep work out of the way so when the coding period begins, people are actually able to write code every day, not get started, not research, not study code, etc. It's usually recommended to intentionally schedule a little bit of time every day. Time management, especially with overlapping school work, is a skill in itself but worthwhile (and in many instances, absolutely necessary).
Sean (May 21 2019 at 02:50):So looking over your plan, I have to say that it is lacking in details. You really will to have more of a specific plan, particularly with regards to the milestones. It also has a few items in it that are probably too far out of scope for your abilities. I suggest, for example, that you drop plans for adding angular dimensions. It's very important that simple text labels with leader lines is working solid and well before moving on to other annotation types.
Louis Googl (May 21 2019 at 13:11):pasted image i have a problem in building on windows any ideas?
Louis Googl (May 21 2019 at 15:02):@Sean you mean programming details? Like which functions i will change?
Sean (May 21 2019 at 15:04):No that’s way too specific
Sean (May 21 2019 at 15:05):You say what at a very high level but nothing about how
Sean (May 21 2019 at 15:09):This is no longer a proposal, it’s a project plan. It should be more specific than your proposal on what you are doing and how you plan to go about doing that.
If you don’t know what to write yet, then you are behind in studying the code and will need to put in more study effort.
Louis Googl (May 22 2019 at 04:30):@Daniel Rossberg I have submitted the patch for annotation points to origin
Louis Googl (May 22 2019 at 04:32):@Sean yes you are correct I have to put more effort in studying the code . so the details is mentioning every type of annotations and describing how I will do it ?
Louis Googl (May 22 2019 at 04:34):@Daniel Rossberg Mr. Daniel you asked me how to calculate the dimensions of the box surrounding the label , I have mentioned an Idea in the project page https://brlcad.org/wiki/User:Ali_Haydar/GSOC19/project , tell me what do you think ? thank you
Sean (May 22 2019 at 14:32):@Louis Googl try updating. I think you just caught a typo (missing open curly brace) on the previous commit that was fixed a few minutes later. Bad timing.
Sean (May 22 2019 at 14:42):Sean yes you are correct I have to put more effort in studying the code . so the details is mentioning every type of annotations and describing how I will do it ?
It's not about breadth, it's about depth. Even for the first one you listed, to fix labels -- what exactly does that mean? What's currently wrong? What are you going to fix? How long do you think it'll take to fix it? How will you know when it's fixed? Are there any documentation or tests needed? ... there's questions like that you can answer already for every one of your major milestones.
It's also probably more work that you realize to be thorough, so you may find that you need to reduce your milestones. I recommend added a week-to-week plan so you can have an idea what will be worked on each week, to help make sure you are not planning to do too much.
Sean (May 22 2019 at 15:57):@Louis Googl Please make sure you complete the Checklist ASAP. I believe you are the last one to add yourself to http://brlcad.org/wiki/Google_Summer_of_Code/2019 ... Please check the other steps as well to make sure you've not missed anything.
Louis Googl (May 22 2019 at 17:24):@Sean I am very sorry for being late , it was because of building on windows Now it works there is another error other than the brace I will send it to you. and because of the trip to Poland , my flight is tomorrow morning , I am working my best in this conditions . now I under stand what you mean by details I will try to fix some thing today. and because of google problem .
Daniel Rossberg (May 22 2019 at 18:25):Daniel Rossberg I have submitted the patch for annotation points to origin
I've seen it, but it doesn't compile, at least on Linux. And, I've a bad feeling with it, because for me it looks like an OpenGL issue. But, I'll test your patch - when it builds.
Daniel Rossberg (May 22 2019 at 18:39):@Louis Googl Please don't promise something you can not keep. For example extending the mged in command: You should not put your main emphasis on the dimension line but enabling the creation of arbitrary vlists.
Daniel Rossberg (May 22 2019 at 18:42):Daniel Rossberg Mr. Daniel you asked me how to calculate the dimensions of the box surrounding the label , I have mentioned an Idea in the project page https://brlcad.org/wiki/User:Ali_Haydar/GSOC19/project , tell me what do you think ? thank you
Do you have an idea of how to code this in the vlist structure?
Louis Googl (May 22 2019 at 18:55):@Daniel Rossberg Until now no but i think i can give you specific answer in 2 days or tomorrow at night
Louis Googl (May 22 2019 at 18:55):But the idea is okay?
Louis Googl (May 22 2019 at 19:20):@Daniel Rossberg it is not compile because the annot_point has to be fastf_t not point_t as you can see in the picture in general channel I am sorry i put it by mistake
Louis Googl (May 22 2019 at 19:24):But what do you mean by arbitrary vlist? It has to be described as one of the types of the annotations correct?
Sean (May 23 2019 at 02:20):@Louis Googl if you're going to submit a patch, please make sure that it compiles and works for you, otherwise you will be wasting other people's time. mistakes can obviously happen and that's okay too, just not a great first impression... :)
Daniel Rossberg (May 24 2019 at 07:15):But what do you mean by arbitrary vlist? It has to be described as one of the types of the annotations correct?
I see that I was a bit vague.
First, there are no annotation types and probable won't be. There could be different in commands for mged and archer which make it easier to create annotations for different uses, but the core of the annotation will always be a segment list rt_annot_internal->ant->segments. This list consists of any number of segments with type line_seg, carc_seg, nurb_seg, bezier_seg, and txt_seg. Now, it would be on you to write a general input method for any of these sequences. Maybe because the annotation is similar to the sketch, the code for the sketch primitive may provide some help here.
Louis Googl (May 25 2019 at 14:43):But the idea is okay?
@Daniel Rossberg I manged to draw the box around a label by code pasted image
Louis Googl (May 25 2019 at 15:01):
Louis Googl (May 25 2019 at 15:25):I am shy to post the code because you will see my mind naked :sweat_smile: Its not the prefect solution and I don't know if this is the right place to put the code , and this is not the best way to modify the list I should have used RT_ADD_VLIST but I didn't find its Definition
Louis Googl (May 25 2019 at 15:27):
Louis Googl (May 25 2019 at 15:46):Louis Googl if you're going to submit a patch, please make sure that it compiles and works for you, otherwise you will be wasting other people's time. mistakes can obviously happen and that's okay too, just not a great first impression... :)
@Sean
sorry for the inconvenience it will not happen again
Louis Googl (May 25 2019 at 22:59):and I adjusted this so the text don't touch the box
pasted image
Louis Googl (May 25 2019 at 22:59):like this pasted image
Louis Googl (May 26 2019 at 13:18):@Sean I think I completed the check list please give me your feed back on the time table and millstones.
Daniel Rossberg (May 26 2019 at 17:48):I am shy to post the code because you will see my mind naked :sweat_smile: Its not the prefect solution and I don't know if this is the right place to put the code , and this is not the best way to modify the list I should have used RT_ADD_VLIST but I didn't find its Definition
But you got an impression about what's necessary to draw the box, which points (coordinates) you need and how to handle them? Is it possible to code this somehow in the rt_annot_internal structure?
BTW, RT_ADD_VLIST is defined in include/rt/global.h. I used grep to find it.
Louis Googl (May 26 2019 at 20:06):pasted image
this is the code I wrote it in dm-wgl.c , yes I have the idea about the points and how to calculate them and add them to the vlist but not in a professional way you can see the code. I don't know if it can be written in rt_annot_internal but it has to be written in a place where the label vlist is already constructed .
Louis Googl (May 26 2019 at 20:09):I will see if I can put it in rt_annot_internal .
Daniel Rossberg (May 27 2019 at 17:22):I've reviewed your patch (https://sourceforge.net/p/brlcad/patches/525/). This is the result with OpenGL: OpenGL_new.png and with X Window X_new.png.
But it should look like this: right.png which is the current X Window depiction. The .g file I used is annot_origin.g
Daniel Rossberg (May 27 2019 at 17:35):@Louis Googl The X Window depiction is correct and the OpenGL version wrong. Every change you are doing on code which is used by both graphic libraries isn't likely to be helpful. You have to start working with the OpenGL code.
BTW, screen shots are not optimal for publishing code work. You can upload patch files here instead.
Louis Googl (May 29 2019 at 11:01):@Daniel Rossberg
pasted image
this is the result for me it works you are right i shouldn't adjust a code used by the two libraries but the as you can see
pasted image
the annot_ip->verts[1] is not the correct point am I correct ?
Louis Googl (May 29 2019 at 11:05):Louis Googl The X Window depiction is correct and the OpenGL version wrong. Every change you are doing on code which is used by both graphic libraries isn't likely to be helpful. You have to start working with the OpenGL code.
BTW, screen shots are not optimal for publishing code work. You can upload patch files here instead.
@Daniel Rossberg I think if I asked a stupid question is better that wasting time :joy: what OpenGl code you mean ? the codes that i am modifying is responsible of drawing the annotation in the wire frame so it interact with the graphic library used for that. can you help me more to know what code you are talking about ?
Louis Googl (May 29 2019 at 11:32):boxdrawing.patch space_between_box_and_label.patch
this is the codes I changed to draw the box around the label . but I have a question the vlist is constructed from 35 points always ? if we are going to add the box coordinates we need 5 points what if the label takes the hall vlist we will have a problem with memory allocation . any suggestions ?
Louis Googl (May 29 2019 at 11:33):boxdrawing.patch space_between_box_and_label.patch
this is the codes I changed to draw the box around the label . but I have a question the vlist is constructed from 35 points always ? if we are going to add the box coordinates we need 5 points what if the label takes the hall vlist we will have a problem with memory allocation . any suggestions ?
@Shubham Rathore where do you think is the better place to put such logic ? and please give me feed back about the code practice thank you.
Daniel Rossberg (May 29 2019 at 19:52):pasted image
the annot_ip->verts[1] is not the correct point am I correct ?
Probably not, the piece of code you are referring is in annot.c. I don't know what's your problem with this line, but, it's very simple to find out: Write a fix that works with both the X Window and OpenGL versions. As the X Window version already works, I expect the code changes in OpenGL. Let's see, how long do you need to find out what's wrong there.
Daniel Rossberg (May 29 2019 at 19:57):Louis Googl The X Window depiction is correct and the OpenGL version wrong. Every change you are doing on code which is used by both graphic libraries isn't likely to be helpful. You have to start working with the OpenGL code.
BTW, screen shots are not optimal for publishing code work. You can upload patch files here instead.
Daniel Rossberg I think if I asked a stupid question is better that wasting time :joy: what OpenGl code you mean ? the codes that i am modifying is responsible of drawing the annotation in the wire frame so it interact with the graphic library used for that. can you help me more to know what code you are talking about ?
No, this code in annot.c doesn't draw the stuff but creates a vlist. This vlist is drawn by a display manager. The X Window display manager (src/libdm/dm-X.* ) seems to be OK, the OpenGL display managers (src/libdm/dm-ogl.* , src/libdm/dm-wgl.* ) seem to have issues.
Daniel Rossberg (May 29 2019 at 20:02):boxdrawing.patch space_between_box_and_label.patch
this is the codes I changed to draw the box around the label . but I have a question the vlist is constructed from 35 points always ? if we are going to add the box coordinates we need 5 points what if the label takes the hall vlist we will have a problem with memory allocation . any suggestions ?
You modified the display manager, but to have this in rt_annot_plot() could be better, because all display managers would use this. However, concentrate on the bugs first.
Shubham Rathore (May 31 2019 at 14:11):Hello @Louis Googl , sorry I was travelling in the last few days hence couldn't reply to your thread. Meanwhile could you share the link to your daily logs. I couldn't find it on the wiki. :)
Sean (May 31 2019 at 21:31):First, there are no annotation types and probable won't be.
Eventually there may be. The current approach is static and declarative, which is obviously not very flexible nor adaptable. We'll want annotations that are both static and dynamic, e.g., a linear dimension that updates as the thing it is pointed to changes in size. If/When we add support for decorators, that may not be suited well to vlists too (e.g., switching to a stippled leader line or a thicker line with different types of arrows on the endpoints, etc).
Sean (May 31 2019 at 21:36):I am shy to post the code because you will see my mind naked :sweat_smile: Its not the prefect solution and I don't know if this is the right place to put the code , and this is not the best way to modify the list I should have used RT_ADD_VLIST but I didn't find its Definition
I know it's easier to say than to do it, but you do not need to be shy when it comes to open source software development. You'll quickly learn that we're all constantly learning and forgetting and relearning and finding new/better ways and just trying to work together to make this all better. We might even have different ideas on how to go about doing that and not always agree, and that's okay too.
The advice I would recommend is to at least always try your best, check your work, try to figure things out first, but then ask for help when you need it. Sharing code for feedback is also very different from submitting code for integration. If you're going to submit a patch to the tracker, you should make sure it applies, compiles, and works for you first. If you're just getting feedback, though, you can share that code all day every day without fear.
Louis Googl (Jun 02 2019 at 03:21):I expect the code changes in OpenGL. Let's see, how long do you need to find out what's wrong there.
Daniel Rossberg I think I am going to stay all summer here :grinning: , 48 h of trying no thing works , my findings the annotation is a vlist eventually the regular vlist is resized but the annotation vlist is not but I didn't find any deference in the dm-vars between a regular vlist and annotation vlist . so its not clear how the program knows this is an annotation vlist Shubham Rathore we need your help here.
Louis Googl (Jun 02 2019 at 03:25):@Daniel Rossberg by searching the way to make an object stay in the same size after zooming is done by reverse the zooming factor and adjusting the display matrix accordingly am I going in the right way ?
Louis Googl (Jun 02 2019 at 03:30):I tried to compare the logic in dm-x.c and dm-wgl.c but for me its like comparing tomatoes and apples because I know some opengl but I don't know any thing about X11 programming . any help will be great Thank you . as it is working in xwindow can I work on the goals of the project keeping this bug in mind , trying to fix it on the way ?
Shubham Rathore (Jun 02 2019 at 08:19):@Louis Googl Regarding the bounding box, we need a solid logic to emboss the feature into annot.c(plot) , we'll not want to use any kind of hack for this functionality. As far as your patch is concerned, it doesn't solve the issue (I tried it on macos), anyway the solution ought to be platform independent.
If you might have noticed, in X window the annotations always remain in the plane of the screen whereas this isn't the case in opengl. I suggest you to thoroughly go through the display manager code, to get a better insight.
P.S. - another unusual behavior that I noticed on my system was that:
1) I rendered an annotation that was supposed to point at the origin, but it didn't.
2) In a separate case, I first rendered a sphere with its centre at the origin. Then I rendered an annotation that was supposed to point at the origin and guess what, it pointed at the origin!
We'll have to work on this too !
Shubham Rathore (Jun 02 2019 at 09:53):I expect the code changes in OpenGL. Let's see, how long do you need to find out what's wrong there.
Daniel Rossberg I think I am going to stay all summer here :grinning: , 48 h of trying no thing works , my findings the annotation is a vlist eventually the regular vlist is resized but the annotation vlist is not but I didn't find any deference in the dm-vars between a regular vlist and annotation vlist . so its not clear how the program knows this is an annotation vlist Shubham Rathore we need your help here.
I didn't completely understand your question; vlist is just a list of vectors that's generic, basically the display information, that the display manager uses to render. In the case of annotation, the vlist will have a reference to the line seg and the string that the dm will render sequentially. I'll suggest to go through the dm- ogl and dm-wgl for a better overview.
Daniel Rossberg (Jun 02 2019 at 10:57):Daniel Rossberg by searching the way to make an object stay in the same size after zooming is done by reverse the zooming factor and adjusting the display matrix accordingly am I going in the right way ?
Write it in code, test it, and post it here (as .patch, not a screen shot) for questions. It's time to code! Your development log has still no entry for the last week.
I would expect, that the OpenGL code for face plates could provide some help in how to draw something "directly" on the screen. Maybe, you can reuse the faceplate_mat and shift it to the right place.
Louis Googl (Jun 02 2019 at 21:58):I didn't completely understand your question; vlist is just a list of vectors that's generic, basically the display information, that the display manager uses to render. In the case of annotation, the vlist will have a reference to the line seg and the string that the dm will render sequentially. I'll suggest to go through the dm- ogl and dm-wgl for a better overview.
@Shubham Rathore the question is a regular vlist doesn't have to be in the plane of the screen and can be zoomed but the annotation vlist stay in the plane of the screen so there is something to tell the program this is annotation vlist which I didn't find any condition in the dm-X.c or in dm-wgl.c can you tell me how it knows this is an annotation vlist ?
Shubham Rathore (Jun 03 2019 at 07:47):Ah okay, have a look into bn/vlist.h, you'll find two defines namely, BN_VLIST_DISPLAY_MAT and BN_VLIST_MODEL_MAT. And also there are mod_mat and disp_mat in x_vars in dm-X.h. X-drawVlist() in dm-X.c has the logic behind mod_mat and disp_mat i.e. the logic behind the plane of the screen display. Just go through these files precisely and you'll find answers to all the dm related queries.
Daniel Rossberg (Jun 04 2019 at 07:17):@Louis Googl Your development log https://brlcad.org/wiki/Ali_Haydar_Dev_log is still empty and I'm not aware of any code you've written last week. How do you want to catch up?
Daniel Rossberg (Jun 04 2019 at 07:32):The flag BN_VLIST_DISPLAY_MAT tells the display manager to switch to a transformation with the following properties:
The z coordinate becomes relevant when we distinct between the paper plane and the screen plane, e.g. when creating blueprints sometime.
Louis Googl (Jun 05 2019 at 07:17):@Daniel Rossberg I am very sorry I am working very hard but with no results in opengl i have tried every thing it didn't work I noticed that the model matrix in dm-X is the same in dm-ogl but the order is different and I noticed a modification on the display matrix in dm-x I tried to do the same in opengl but the result is a leader line with no annotation pasted image in this picture you can see i have tried to copy the logic from dm-x but it didn't work and the description you put in the last message correspond to glOrtho I tried it too but it didn't work , I am not quitting the problem but i am going to start with my functions and keep learning opengl and trying to fix it today I will try to finish the bounding box function and see what happens and i will update the dev_log soon
Louis Googl (Jun 05 2019 at 07:18):maybe its over the level of my experience.
Daniel Rossberg (Jun 05 2019 at 07:33):maybe its over the level of my experience.
Maybe, but you can gain new experience, what GSoC is for too.
I try to guide you, but you had to follow my advice. I already wrote you, that I expect that it should work somehow similar to the face-plate mode. There is a faceplate_mat which could be useful. And, what is wgl_normal() doing?
Maybe, you can create another attempt with this information, post its code here in patch file format, and discuss it here.
Louis Googl (Jun 06 2019 at 05:51):I am not leaving it i will fix it but I want to write some thing :grinning:
Louis Googl (Jun 06 2019 at 05:54):@Daniel Rossberg ant_label_box1.patch this is the function to draw a box around the label it works for wgl ogl X but just for short label if the label was long 2 letters :grinning: there will be a memory allocation problem can you look at it and tell me what do you think about the code and the memory error thank you .
Louis Googl (Jun 06 2019 at 05:58):pasted image
pasted image
this what happens when I called my function after calling the macro which set the model matrix so i think this will help me fix the projection problem in opengl
Louis Googl (Jun 06 2019 at 06:00):I didn't sleep for two days the rule of four hours a day is not working with me :grinning: :sunglasses:
Louis Googl (Jun 06 2019 at 06:07):pasted image final result
Louis Googl (Jun 06 2019 at 06:09):Maybe, but you can gain new experience, what GSoC is for too.
this is my first goal I will keep trying with it. thank you
Daniel Rossberg (Jun 06 2019 at 07:57):I'll have a look at it today night.
Louis Googl (Jun 06 2019 at 18:58):pasted image the memory problem is fixed when I used RT_ADD_VLIST but I faced another one you can see it in this picture.
Louis Googl (Jun 06 2019 at 19:00):I think it is because the long annotation is constructed from more than one vlist I am working on fixing it
Daniel Rossberg (Jun 07 2019 at 08:48):@Louis Googl Please have a look at the BRL-CAD revision 73265.
Louis Googl (Jun 07 2019 at 19:49):@Daniel Rossberg the revision of the patch is not correct ?
Daniel Rossberg (Jun 07 2019 at 21:03):I mean the revision in BRL-CADs subversion repisitory.
Louis Googl (Jun 07 2019 at 21:51):pasted image I fixed the problem of long annotation
Louis Googl (Jun 08 2019 at 00:43):ant_label_box.patch this is the function it works perfectly I hope
Louis Googl (Jun 08 2019 at 00:45):I mean the revision in BRL-CADs subversion repisitory.
I didn't understand what should I do? I made the patch on this revision it is not the head revision ?
Louis Googl (Jun 08 2019 at 03:06):@Daniel Rossberg the display matrix is fixed :slight_smile:
Daniel Rossberg (Jun 08 2019 at 16:37):pasted image final result
@Louis Googl How have you done this? I don't mean the box but to display an annotation with a single number only.
Louis Googl (Jun 08 2019 at 16:56):@Daniel Rossberg the same way this good man did it @Chetan Shinde
Daniel Rossberg (Jun 08 2019 at 17:16):ant_label_box.patch this is the function it works perfectly I hope
For the one line and text annotation maybe, but even there, not all annotations shall be displayed in a box. Rather, there is a list of geometric primitives in rt_annot_internal->ant which should allow the exact definition of how the result shall look like.
However, you know now what's necessary to draw the lines of a box. You need a reference to entry in rt_annot_internal->ant.segments, or to be more precise, the bounding box of the segment. Then you add an offset to the points an draw the lines between them.
I.e., you know what's missing in the current annotation primitive: The possibility to refer to other segments (or other segments' bounding boxes), add offsets to points, etc.. Can this be done with the current segment structs or do we need new ones?
One possibility would be to use negative indices for the vertices. I.e., to use the minus sign as a flag for something special. The index of the referenced segment, the corner of the bounding box, and the offsets could be coded in the remaining bits of the integer.
Or, you might consider this as improper, and want to extend the rt_annot_internal structs instead.
Daniel Rossberg (Jun 08 2019 at 17:31):Daniel Rossberg the same way this good man did it Chetan Shinde
You mean the disp_mode in the bounding box computation? This shouldn't be the reason, because why should the content or length of the text matter there? I.e., there is probable something more behind this ...
Louis Googl (Jun 08 2019 at 18:17):You mean by the segments the words in one annotation? We want to put line between words ? There is another thing you cant put a label with two words without the under dash because the entering in mged is like a c console we should do something about that?
Louis Googl (Jun 08 2019 at 18:18):Yes it is the disp_mode i will try another way .
Chetan Shinde (Jun 08 2019 at 21:04):Daniel Rossberg the same way this good man did it Chetan Shinde
Thanks @Louis Googl for the complement! :grinning: , means a ton!
Chetan Shinde (Jun 08 2019 at 22:14):Daniel Rossberg the same way this good man did it Chetan Shinde
You mean the disp_mode in the bounding box computation? This shouldn't be the reason, because why should the content or length of the text matter there? I.e., there is probable something more behind this ...
Knowing, for what reason disp_mode, is been used will help us to understand why the error is occurring.Can we ask @Shubham Rathore.
@Shubham Rathore can you please help us with it...
Patch link where disp_mode has been introduced.
https://sourceforge.net/p/brlcad/patches/471/#cd2e
Thanks.
Louis Googl (Jun 09 2019 at 01:18):@Chetan Shinde : but why you had this idea ? what lead you that the disp_mode is the problem ?
Chetan Shinde (Jun 09 2019 at 07:50):There is inbuilt logic in brlcad which is used for plotting any character on the screen. The logic defines how the lines are to be drawn, with consideration to a reference point. now the bn_vlist_bbox function where the disp_mode is defined is responsible for the rendering of the text.
the rendering is done, by calculating the points which are actually to be plotted with the help of line no. 89 to 94 in the vlist file.
turning the disp_mode =1 shortcircuits the code and the line no 89 to 94 are not reached.
You can observe, this by initially trying to render a single 1 with disp_mode not been commented. and then again debugging the code with disp_mode = 1 been commented. We observed in the former case that once the disp_mode gets set to 1 it never turn to zero again and the for loop jumps to the next iteration.
Daniel Rossberg (Jun 09 2019 at 14:43):now the bn_vlist_bbox function where the disp_mode is defined is responsible for the rendering of the text.
This is not true. bn_vlist_bbox() doesn't draw anything. It calculates a min and max point (bmin. bmax) only.
Daniel Rossberg (Jun 09 2019 at 14:47):You mean by the segments the words in one annotation? We want to put line between words ? There is another thing you cant put a label with two words without the under dash because the entering in mged is like a c console we should do something about that?
I mean with segments the segments in rt_annot_internal or rather it substructure. Are you familiar with it?
Louis Googl (Jun 09 2019 at 16:04):I know there is segments inside rt_ant but i don't know what they represent it is not obvious . can you explain more ?
I think that you are thinking of making the annotation as line segment and curve segment and text segment ? if so we don't have curve segment yet ? and we want to make one and this curves has to be static ? or can be manipulated ?
Daniel Rossberg (Jun 09 2019 at 16:05):What I could see in bn_vlist_bbox() is, that there is a special treatment for vlists which consist of a single point only. This is probable done, because from the bounding box the size of the drawing s_size is computed. And, if this size is 0, the vlist won't be drawn (see ratio in dm_draw_display_list()).
The bounding box of an annotation will be determined from a single point as well.
Daniel Rossberg (Jun 09 2019 at 16:09):I know there is segments inside rt_ant but i don't know what they represent it is not obvious . can you explain more ?
I think that you are thinking of making the annotation as line segment and curve segment and text segment ? if so we don't have curve segment yet ? and we want to make one and this curves has to be static ? or can be manipulated ?
Why do you think that annotations can't have curve segments? They can have lines, arcs, NURBs, Bezier curves, and texts in any order and number right now. Look at src/librt/primitives/annot/annot.c!
Shubham Rathore (Jun 09 2019 at 16:14):I know there is segments inside rt_ant but i don't know what they represent it is not obvious . can you explain more ?
I think that you are thinking of making the annotation as line segment and curve segment and text segment ? if so we don't have curve segment yet ? and we want to make one and this curves has to be static ? or can be manipulated ?
There are a number of segment types, i.e. txt, line, curve , nurbs, beizer. The current support only encompasses a line and a text segment. ant->count is the count of the number of segments present in the primitive container and ant->segments has the pointers to the segments present. I suggest you to go through the import function in the annot.c for a better overview.
Daniel Rossberg (Jun 09 2019 at 16:17):@Louis Googl
First, you should eliminate the shortfalls of the current annotations. I.e. fix the bugs, enlarge the mged (and archer) commands to input arbitrary annotations (as they are currently possible), ....
You may remember this post of mine mentioning to enlarge the mged (and archer) commands to input arbitrary annotations (as they are currently possible). This refers to the input of arbitrary segment lists.
Louis Googl (Jun 10 2019 at 00:30):@Daniel Rossberg @Shubham Rathore now I understand we have the CURVE_CARC CURVE_NURB CURVE_BEZIER which can be made as vlist in the function seg_to_vlist but we have to allow the user to enter their properties through the annot menu?
Louis Googl (Jun 10 2019 at 00:30):then I have to obtain a pointer to the segment to draw a box around it if the user wants?
Louis Googl (Jun 10 2019 at 00:31):I am trying to imagine your Idea, am I correct?
Shubham Rathore (Jun 10 2019 at 06:41):There is inbuilt logic in brlcad which is used for plotting any character on the screen. The logic defines how the lines are to be drawn, with consideration to a reference point. now the bn_vlist_bbox function where the disp_mode is defined is responsible for the rendering of the text.
the rendering is done, by calculating the points which are actually to be plotted with the help of line no. 89 to 94 in the vlist file.
turning the disp_mode =1 shortcircuits the code and the line no 89 to 94 are not reached.
You can observe, this by initially trying to render a single 1 with disp_mode not been commented. and then again debugging the code with disp_mode = 1 been commented. We observed in the former case that once the disp_mode gets set to 1 it never turn to zero again and the for loop jumps to the next iteration.
This isn't exactly true ! disp_mode is just a flag that tells the application to use the plane of the screen or not.
Shubham Rathore (Jun 10 2019 at 06:49):Daniel Rossberg Shubham Rathore now I understand we have the CURVE_CARC CURVE_NURB CURVE_BEZIER which can be made as vlist in the function seg_to_vlist but we have to allow the user to enter their properties through the annot menu?
To include nurb or beizer into the annotation, we'll have to prompt the user to enter the corresponding details. Currently there is no support for that ! Let me again tell you, our main focus as of now is to make the normal leader lines work i.e. remove all the existing bugs before adding other features or functionalities. Once the bugs in the basic leader lines are sorted, it wont be a difficult task to emboss other features.
P.S. : You are not uploading your daily logs despite being reminded by all the mentors. Dev logs are very essential for the mentors to see if you are going in the right direction or not. Kindly update your logs. Regarding the code, there happens to be one relevant submitted patch that doesn't solve anything. Please give some more time to the code base and come up with some acceptable patches.
Louis Googl (Jun 10 2019 at 14:37):pasted image for the leader line pointing to origin this picture proves that it is not, you can see the vlists I draw shows the real coordinates that the leader line is pointing to am I wrong?
Daniel Rossberg (Jun 10 2019 at 14:55):The "leader line origin" bug was fixed with my patches to dm-wgl.c and dm-ogl.d. They are included in the BRL-CAD repository and can be retrieved with a svn update.
Sean (Jun 10 2019 at 14:57):There are specific steps in the BUGS file you can check, and a separate bug (numbers as a label) you can test too.
Daniel Rossberg (Jun 10 2019 at 15:01):@Louis Googl
What I could see in bn_vlist_bbox() is, that there is a special treatment for vlists which consist of a single point only. This is probable done, because from the bounding box the size of the drawing s_size is computed. And, if this size is 0, the vlist won't be drawn (see ratio in dm_draw_display_list()).
The bounding box of an annotation will be determined from a single point as well.
For the next bug-fix you can start here. Try to understand everything I wrote there, and come up with a patch.
Louis Googl (Jun 10 2019 at 22:30):@Daniel Rossberg I fixed it, it works but I don't know which solution you prefer, the error is produced with any solid constructed from less than 35 points we can fix it either by treating it like a point as you suggested pointfix.c.patch in this case the s_size will always be 2 for any solid that has less than 35 points there is another way to fix it by changing the condition that makes the loop sees just the first point in the first 35 points of the solid conditionfix.c.patch in this case when cmd = 16 which is the enum BN_VLIST_MODEL_MAT this exists in cmd at the end of the solid points wither it was constructed from 35 points or more ( in this case the s_size is calculated correctly always not just 2 for short solids or we can just omit the disp_mode from the condition like this condition.c.patch which also works and calculate the s_size correctly .
Louis Googl (Jun 10 2019 at 22:41):and I don't see the need for this condition because the loop will end automatically when i=nused for each list of the solid it may be useful just to make fewer comparisons between points coordinates but it is not very crucial in my opinion.
Sean (Jun 10 2019 at 22:41):@Louis Googl I've just read what you wrote twice and still am not sure what you're saying. so much punctuation missing... but the gist to me seems to be some strictly defined C container is causing a problem, yes? what exactly is the problem, the error?
Louis Googl (Jun 10 2019 at 22:44):the error is when the solid constructed from one vlist less than 35 points this comparison occurs just for the first point pasted image
Louis Googl (Jun 10 2019 at 22:45):pasted image because of this condtion
Louis Googl (Jun 10 2019 at 22:47):the error is when the solid constructed from one vlist less than 35 points this comparison occurs just for the first point pasted image
because of this, the s_size is being zero for solids which have just one vlist.
Louis Googl (Jun 10 2019 at 23:00):the bottom line is the s_size is not calculated correctly because of this condition.
Daniel Rossberg (Jun 11 2019 at 08:57):The answer to the miracle why the length of the annotation matters is not in bu_vlist_bbox() but in the function calling it ;)
Daniel Rossberg (Jun 11 2019 at 09:08):The pointfix.c.patch is wrong, because it changes the bounding boxes for lines and triangles as well.
As I've already said: An annotation has only a single point (the reference point) in the model space. The other points are all in display coordinates. Because it's hard to predict, with which points in the model space they will coincide, it's reasonable to ignore them. To simply ignore the matrix flags would be definitely wrong.
More interesting is the question regarding the role of the vlist length. You can find it out when looking at the function which calls bu_vlist_bbox(). There you can see, that the vlist has a very special construction ...
I could imagine, that there could be something improved regarding the matrix flags there too.
Daniel Rossberg (Jun 11 2019 at 17:16):@Louis Googl What were you working on today? Did you debugged bu_vlist_bbox() and saw how it's called with a short and a long annotation?
Louis Googl (Jun 11 2019 at 17:37):I just started I was going to update the log for not accepted solutions.
Daniel Rossberg (Jun 11 2019 at 17:46):But, this was today morning ;)
However, it looks like you worked at night. Therefore, for today night I recommend to debug bu_vlist_bbox() and explore its behavior and usage.
Louis Googl (Jun 11 2019 at 17:59):actually, a usually work at night I had an oral interview with a professor at the university and just came back and started working I am making long and short annotations and see what happens when bound_solid() calls bu_vlist_bbox() in the two cases.
Daniel Rossberg (Jun 11 2019 at 18:04):Working at night is quite OK. People here work in different time zones anyway.
Louis Googl (Jun 11 2019 at 18:09):you said that all the points of the annotation should be ignored just considering reference point which is happening with short annotations but in long annotations the points in the second vlist is not ignored that what makes the s_size is correct for long annotations again because of the condition at the top of the loop { if(disp_mode == 1 && *cmd != BN_VLIST_MODEL_MAT) }
Daniel Rossberg (Jun 11 2019 at 18:28):Let me correct some misunderstanding here, which hopefully makes things more clear:
There is no second vlist but only one: sp->s_vlist in bound_solid()
But, it's organized in chunks. For short annotation one chunk is enough, but longer annotations need more than that.
And there is the second misunderstanding: s_size is not correct with the second chunk
In the second run of bu_vlist_bbox() the points are interpreted as model-space points, but they are in fact in display coordinates, which may result in a wrong bounding box.
Louis Googl (Jun 11 2019 at 19:03):I didn't mean it is correct correct I meant it is not zero so the things are drawn, what I understand is we have to treat the annotation as one point so we have to call bb_box() in a different way in bound_solid() pseudo " if this solid represent annotation call bbox() with a vlist contains one point(refrance point) and cmd[0]=12 " am I correct ? but I don't know what the difference between a solid contains a sphere and a solid contain an annotation.
Louis Googl (Jun 12 2019 at 00:54):onetry.patch
here another try it ignores all the points of long annotation, but I am not feeling good about putting the disp_mode under the BN_VLIST_POINT_DRAW I hope it is correct or close to the approach you are thinking about.
Daniel Rossberg (Jun 12 2019 at 16:48):Try to separate the two things:
Maybe, its easier to start with a patch for the first bullet only. Here, I can't see your motivation for moving the disp_mode = 1; around. It looks like you forgot something there.
And for the second bullet, you can't assume that the annotation is alone in the vlist.
Louis Googl (Jun 12 2019 at 16:51):I moved the disp_mode because if I didn't change it the other points will be seen in the first chunk.
Louis Googl (Jun 12 2019 at 16:51):so there is no way to know what the solid vlist contains ?
Daniel Rossberg (Jun 12 2019 at 16:52):I moved the disp_mode because if I didn't change it the other points will be seen in the first chunk.
??? Which points?
Daniel Rossberg (Jun 12 2019 at 16:53):so there is no way to know what the solid vlist contains ?
You see the BN_VLIST_~ macros? This is what a vlist can contain.
Louis Googl (Jun 12 2019 at 16:55):the points that we wanted to ignore in the first place they are ignored because when cm[0]=BN_VLIST_DISPLAY_MAT the disp_mode became 1 and I changed cmd[0] =BN_VLIST_POINT_DRAW so the disp_mode is still zero and the loop is entering the points that are in display coordinates
Daniel Rossberg (Jun 12 2019 at 16:58):I didn't mean it is correct correct I meant it is not zero so the things are drawn, ...
@Louis Googl Think twice, before you write something down. It's important to be precise.
Louis Googl (Jun 12 2019 at 17:00):sorry I didn't think it is important because considering the annotation as a point will not get us a correct size any way
Daniel Rossberg (Jun 12 2019 at 17:01):the points that we wanted to ignore in the first place they are ignored because when cm[0]=BN_VLIST_DISPLAY_MAT the disp_mode became 1 and I changed cmd[0] =BN_VLIST_POINT_DRAW so the disp_mode is still zero and the loop is entering the points that are in display coordinates
cmd[0] =BN_VLIST_POINT_DRAW what's that? (see my previous post)
And, you shall ignore the display coordinates!
Louis Googl (Jun 12 2019 at 17:05):The other points are all in display coordinates. Because it's hard to predict, with which points in the model space they will coincide, it's reasonable to ignore them. To simply ignore the matrix flags would be definitely wrong.
I could imagine, that there could be something improved regarding the matrix flags there too.
I though if we change the matrix flag it will go to the point case .
Louis Googl (Jun 12 2019 at 17:07):onetry.patch
here another try it ignores all the points of long annotation, but I am not feeling good about putting the disp_mode under the BN_VLIST_POINT_DRAW I hope it is correct or close to the approach you are thinking about.
is there any thing correct in this patch ?
Daniel Rossberg (Jun 12 2019 at 17:15):Only one point of the annotation's vlist shall be considered for the bounding box: The reference point (which is in the model space, the other coordinates are all in the display space). And, this coordinate has to be treat like single point case. Do I need to say more?
Daniel Rossberg (Jun 12 2019 at 17:18):onetry.patch
here another try it ignores all the points of long annotation, but I am not feeling good about putting the disp_mode under the BN_VLIST_POINT_DRAW I hope it is correct or close to the approach you are thinking about.is there any thing correct in this patch ?
Your thoughts were going into the right direction there. You have seen where the issues are. But, it still needs some improvements.
Louis Googl (Jun 12 2019 at 17:19):No I understand but I have to find how to test if this vlist is an annotation vlist and if it is contains just annotation and construct new list contains the reference point only and pass it to the bbox()
Daniel Rossberg (Jun 12 2019 at 17:20):To make it easier for you, I want to separate the two sub-issues (which points to consider and how, vlist in chunks).
Daniel Rossberg (Jun 12 2019 at 17:21):In your last patch you set the disp_mode to 1 if you get the BN_VLIST_POINT_DRAW flag, which is absolute meaningless. Can you do better?
Daniel Rossberg (Jun 12 2019 at 17:24):No I understand but I have to find how to test if this vlist is an annotation vlist and if it is contains just annotation and construct new list contains the reference point only and pass it to the bbox()
I see, you didn't understood: Every annotation has exactly one reference point in the model space. All other points are in the display space. How many doesn't matter. You can test it with the examples you already have.
Louis Googl (Jun 12 2019 at 17:25):so i separated the wanted point correctly ?
Daniel Rossberg (Jun 12 2019 at 17:26):No.
Daniel Rossberg (Jun 12 2019 at 17:27):You set the disp_mode for the BN_VLIST_POINT_DRAW flag. Why that?
Louis Googl (Jun 12 2019 at 17:30):because of this if(disp_mode == 1 && *cmd != BN_VLIST_MODEL_MAT)
Daniel Rossberg (Jun 12 2019 at 17:31):because of this if(disp_mode == 1 && *cmd != BN_VLIST_MODEL_MAT)
I can't see a BN_VLIST_POINT_DRAW there. Does any of your examples contain a BN_VLIST_POINT_DRAW?
Louis Googl (Jun 12 2019 at 17:32):yes but when disp_mode=0 the points that we want to ignore is not ignored
Louis Googl (Jun 12 2019 at 17:33):No I didn't fined how to draw single point in mged
Daniel Rossberg (Jun 12 2019 at 17:34):yes but when disp_mode=0 the points that we want to ignore is not ignored
That's right, to ignore the points in display coordinates you had to set disp_mode to 1. But with your change it will be never set to 1. Debug it!
Daniel Rossberg (Jun 12 2019 at 17:37):Ups, I just saw that you have left the disp_mode line after the case BN_VLIST_DISPLAY_MAT: in your code. Now it makes less sense.
Daniel Rossberg (Jun 12 2019 at 17:38):The disp_mode = 1; after the case BN_VLIST_POINT_DRAW: will probably never be called.
Daniel Rossberg (Jun 12 2019 at 17:38):And I can't see the reason for it.
Louis Googl (Jun 12 2019 at 17:42):can we initialize it to one ?
Daniel Rossberg (Jun 12 2019 at 17:44):You can initialize it to any integer ;)
However, what's your problem with the disp_mode? It works perfectly as it should.
Louis Googl (Jun 12 2019 at 17:46):And I can't see the reason for it.
the reason for it because I changed cmd[0] from BN_VLIST_DISPLAY_MAT to BN_VLIST_POINT_DRAW
Louis Googl (Jun 12 2019 at 17:50):You can initialize it to any integer ;)
However, what's your problem with the disp_mode? It works perfectly as it should.
I know that I can but is this the solution :grinning: i am sorry maybe you are pulling your hair now, but you are not telling me if changing the cmd for the reference point is correct and I have the idea of making a new vlist with one point and cmd[0]=BN_VLIST_POINT_DRAW is this right?
Daniel Rossberg (Jun 12 2019 at 17:51):OK. That's a reason. It won't work if BN_VLIST_DISPLAY_MAT isn't at index 0, but OK.
However, because of this (BN_VLIST_DISPLAY_MAT not at index 0) and the disp_mode is OK in general, this should be treated a different way.
Daniel Rossberg (Jun 12 2019 at 17:53):The BN_VLIST_DISPLAY_MAT reference point has to be treated like the BN_VLIST_POINT_DRAW point. That's all.
Daniel Rossberg (Jun 12 2019 at 18:08):The BN_VLIST_DISPLAY_MAT reference point has to be treated like the BN_VLIST_POINT_DRAW point. That's all.
@Louis Googl Write a patch which implements this. Why do you want to change the flag in bound_solid() when you can do the right thing in bn_vlist_bbox() directly?
Louis Googl (Jun 12 2019 at 19:57):try1.c.patch
this works for the short annotations , is it correct ? it is like changing cmd[0].
Louis Googl (Jun 12 2019 at 19:59):now the problem of annotation constructed from more than one chunk . and whither the vlist contains annotation only
Daniel Rossberg (Jun 12 2019 at 20:15):The patch looks good. You should create a patch task on sourceforge with it
Daniel Rossberg (Jun 12 2019 at 20:17):The issue with the many chunks is, that the disp_mode isn't memorized between them. Do you have an idea how this could be done?
Louis Googl (Jun 12 2019 at 22:07):can you refer to an example about distinguishing the continents of a vlist all the magic in the solid is the same either BU_LIST_HEAD_MAGIC or BN_VLIST_MAGIC and I have searched in the code it seems nobody cares about the continents of the vlist
Louis Googl (Jun 12 2019 at 22:29):if we intialized disp_mode to 1 it works also for the long annotations.
Louis Googl (Jun 13 2019 at 02:07):The issue with the many chunks is, that the disp_mode isn't memorized between them. Do you have an idea how this could be done?
try2.c.patch I tried this it works but I don't know if this is what you are hoping
Daniel Rossberg (Jun 13 2019 at 18:00):For the next patch keep in mind, that the problem arises, because bn_vlist_bbox() forgets about the disp_mode value.
For more variety in the vlist you could put some other objects in the database, ab8s, spheres, etc..
Daniel Rossberg (Jun 13 2019 at 18:04):if we intialized disp_mode to 1 it works also for the long annotations.
It should already "work" with your current patch on sourceforge. The bounding box for the long annotations is not correct yet, but to display it it's enough to have a size greater 0.
Louis Googl (Jun 13 2019 at 19:04):The issue with the many chunks is, that the disp_mode isn't memorized between them. Do you have an idea how this could be done?
try2.c.patch I tried this it works but I don't know if this is what you are hoping
have you seen this patch?
Louis Googl (Jun 13 2019 at 19:08):this way memorize the state of the disp_mode and calculate the bbox() on the reference point coordinates always, or maybe you want to change the bbox() function? and make the disp_mode one of its parameters?
Louis Googl (Jun 13 2019 at 21:41):pasted image I managed to draw a carc between the tow ends of the leader line replacing the text segment by a carc segment Now i will try to make three segments with the entering logic
Louis Googl (Jun 13 2019 at 22:19):I am doing this while you see the patch try2 if it is good or approaches the problem in a good way.
Louis Googl (Jun 14 2019 at 00:50):
Louis Googl (Jun 14 2019 at 03:25):pasted image
at first i couldn't add the third segment it always gives magic not recognised now it works
Daniel Rossberg (Jun 14 2019 at 17:55):this way memorize the state of the disp_mode and calculate the bbox() on the reference point coordinates always, or maybe you want to change the bbox() function? and make the disp_mode one of its parameters?
Yes, I've seen your try2.c.patch. It has however still the old problem, that it makes not necessarily true assumptions about the vlist, e.g. that the display flag is at index 0.
I'm afraid, the only neat solution includes the change of bn_vlist_bbox(). Only bn_vlist_bbox() analyses the vlist the right way.
Daniel Rossberg (Jun 14 2019 at 18:04):pasted image
at first i couldn't add the third segment it always gives magic not recognised now it works
I see that you make yourself familiar with the other segment types. That's good. Do you have an idea how an "in" command could be constructed, such that any combination of segments can be created?
Louis Googl (Jun 14 2019 at 18:12):pasted image
at first i couldn't add the third segment it always gives magic not recognised now it worksI see that you make yourself familiar with the other segment types. That's good. Do you have an idea how an "in" command could be constructed, such that any combination of segments can be created?
I know how to ask for the parameter of each segment and I can imagine how to chose how many segments the user wants to put in the annotation
Louis Googl (Jun 14 2019 at 18:15):but do we want to make ready to use segments or just prompt the user to enter whatever he wants and take care of the placement and you think we should use the same function annot_in() or create another one ? with a dynamic menu for each case?
Daniel Rossberg (Jun 14 2019 at 18:28):I would say, at the first place, it needs a syntax for the in command implemented. Then, this could be supported by prompts.
What came into my mind is, that the annotation is very similar to the sketch. Can something from the sketch primitive be reused for the annotation? There is a graphical sketch editor too.
Louis Googl (Jun 14 2019 at 18:29):Yes, I've seen your try2.c.patch. It has however still the old problem, that it makes not necessarily true assumptions about the vlist, e.g. that the display flag is at index 0.
I'm afraid, the only neat solution includes the change of bn_vlist_bbox(). Only bn_vlist_bbox() analyses the vlist the right way.
so I will make a display list contains more than one primitive and see how it works and changes the bbox() accordingly
Louis Googl (Jun 14 2019 at 18:32):I thought about using the sketch primitive but it is not supported by the in command, the best way is using the sketch editor ?or add support to sketch in the in command ?
Daniel Rossberg (Jun 14 2019 at 20:42):Adding an annotation editor based on the sketch editor in addition to the existing in command?
Louis Googl (Jun 14 2019 at 23:07):No, I meant creating a sketch in sketch editor and put its segments inside the annotation.
Louis Googl (Jun 14 2019 at 23:08):as you described the annotation may be anything or any combination of segments. so creating an annotation will be as hard as creating the model or even more. a lot of CAD programs uses fixed shapes of annotations we are not thinking of that? we want the user to be free to add any segment he wants?
Louis Googl (Jun 15 2019 at 02:37):pasted image
do you think this is the way to expand the segments or make a new in command ?
Louis Googl (Jun 15 2019 at 02:38):the points entered by the user are not final we can adjust them for the positioning of the annotation segments in a nicer way
Louis Googl (Jun 15 2019 at 02:40):there is something weird if you notice the starting and the end points of the carc has the same X coordinates but they don't appear like that in the drawing
Louis Googl (Jun 15 2019 at 02:54):there is something weird if you notice the starting and the end points of the carc has the same X coordinates but they don't appear like that in the drawing
forget this it was my mistake :octopus:
Louis Googl (Jun 15 2019 at 04:03):remember.patch this batch for remembering the display mode
Daniel Rossberg (Jun 15 2019 at 16:59):remember.patch this batch for remembering the display mode
Your patch isn't bad. The only real issue I see is that you forgot to initialize disp_mode.
However, rethinking the whole thing, I think the best solution would be to write a "real" bounding box function for vlists which includes the BU_LIST_FOR loop to. I.e. write a function int bn_vlist_bbox(struct bu_list *vlistp, point_t *bmin, point_t *bmax) which gets the sp->s_vlist as parameter and does the BU_LIST_FOR loop. This function calls then a static int bn_vlist_bbox_internal(struct bn_vlist *vp, point_t *bmin, point_t *bmax, int *disp_mode) which is mainly the current bn_vlist_bbox() function. Both functions would have their implementation in src/libbn/vlist.c.
Louis Googl (Jun 15 2019 at 17:08):I can do that thank you . I will try to submit it today
Louis Googl (Jun 15 2019 at 17:21):pasted image I tried to prompt the user for a carc segment like this what do you think ? if he answers No the annotation the behaviour will be the same as always
Daniel Rossberg (Jun 15 2019 at 17:23):Do you know the graphical sketch editor in mged?
Louis Googl (Jun 15 2019 at 17:23):yes
Louis Googl (Jun 15 2019 at 17:24):and I know how to use it
Daniel Rossberg (Jun 15 2019 at 17:25):Then how about copying its code and make an annotation editor of it?
Louis Googl (Jun 15 2019 at 17:25):it will be a very nice Idea
Daniel Rossberg (Jun 15 2019 at 17:26):There will be an additional segment type, the text, but in general it should be very similar.
Louis Googl (Jun 15 2019 at 17:27):I have read some documentation said that the sketch editor uses the get and put commands under the hood but i couldn't find the Gui code for the sketch editor.
Louis Googl (Jun 15 2019 at 17:31):I will do the research
Daniel Rossberg (Jun 15 2019 at 17:34):src/tclscripts/mged/skt_ed.tcl?
Louis Googl (Jun 15 2019 at 17:39):we are going to add an annotation editor here? in the Create menu pasted image
Daniel Rossberg (Jun 15 2019 at 17:51):Yes. Let's see where this will lead to :)
Louis Googl (Jun 15 2019 at 17:57):I have imagine what you are thinking about , but in this case I have to make changes on the mged gui and the sketch editor gui . do I have to use a gui editor ? or learn how to do it be the existed code ?
Daniel Rossberg (Jun 15 2019 at 18:25):I'm afraid, you have to learn how to do it in code ;)
Louis Googl (Jun 15 2019 at 19:24):Can you advise from where to start?
Louis Googl (Jun 16 2019 at 17:46):first.patch
I don't know if we have to keep the bbox() function in the old implementation but I changed its name and defined new function to call it with the loop as you described
Louis Googl (Jun 16 2019 at 17:48):dodraw.c.patch
here you can see in dodraw.c we have to enter the loop to change the sp->s_vlen I made this changes give me your opinion
Louis Googl (Jun 16 2019 at 17:53):Can you advise from where to start?
you can help me here to save time if you lead me to the place where the event loop of the two Gui exists and where I can find the implementation of the buttons in the mged gui. I am doing the research but I need some help .
Daniel Rossberg (Jun 16 2019 at 18:01):first.patch
I don't know if we have to keep the bbox() function in the old implementation but I changed its name and defined new function to call it with the loop as you described
Make the old function, i.e. bn_vlist_bbox_internal(), static and don't mention it in the header file.
Daniel Rossberg (Jun 16 2019 at 18:07):dodraw.c.patch
here you can see in dodraw.c we have to enter the loop to change the sp->s_vlen I made this changes give me your opinion
BU_LIST_FOR is now in bn_vlist_bbox()!
Daniel Rossberg (Jun 16 2019 at 18:09):bn_vlist_bbox() shouldn't log anything. If it finds an unknown command it should return it.
Louis Googl (Jun 16 2019 at 18:11):I know but we are passing to the bn_vlist_bbox() just the sp->s_vlist so to change the sp->s_vlen we have to pass the hall solid !
Louis Googl (Jun 16 2019 at 18:14):I think the best solution would be to write a "real" bounding box function for vlists which includes the BU_LIST_FOR loop to. I.e. write a function
int bn_vlist_bbox(struct bu_list *vlistp, point_t *bmin, point_t *bmax)which gets the sp->s_vlist as parameter and does the BU_LIST_FOR loop.
I put the loop inside the function as you described her
Daniel Rossberg (Jun 16 2019 at 18:15):I know but we are passing to the bn_vlist_bbox() just the sp->s_vlist so to change the sp->s_vlen we have to pass the hall solid !
Then you have to pass the solid.
Daniel Rossberg (Jun 16 2019 at 18:17):I put the loop inside the function as you described her
I don't look at every detail. This is your work. If you find, that it's better to pass the solid, than it's fine :slight_smile:
Louis Googl (Jun 16 2019 at 18:19):okay , but in the display_list.c the old loop doesn't change the sp->s_vlen , so we have to make another function called by dodraw is this correct ?
Louis Googl (Jun 16 2019 at 18:22):or just keep the loop in its old position.
Daniel Rossberg (Jun 16 2019 at 18:33):Can you advise from where to start?
you can help me here to save time if you lead me to the place where the event loop of the two Gui exists and where I can find the implementation of the buttons in the mged gui. I am doing the research but I need some help .
OK: The first step is to insert annot in the list at line 34 of src/tclscripts/mged/openw.tcl.
Daniel Rossberg (Jun 16 2019 at 18:36):okay , but in the display_list.c the old loop doesn't change the sp->s_vlen , so we have to make another function called by dodraw is this correct ?
This means, that it determines the length of the vlist too? I.e. it would need something like n_vlist_bbox(struct solid* vlistp, point_t* bmin, point_t* bmax, int *length)?
Louis Googl (Jun 17 2019 at 18:07):Can you advise from where to start?
you can help me here to save time if you lead me to the place where the event loop of the two Gui exists and where I can find the implementation of the buttons in the mged gui. I am doing the research but I need some help .
OK: The first step is to insert annot in the list at line 34 of src/tclscripts/mged/openw.tcl.
pasted image
pasted image
need some more help :grinning:
Louis Googl (Jun 17 2019 at 18:11):if I added a new value for the esolint_type which is annot and modified the auto index to a copay of skt_ed named ant_ed this will open the skt_ed if we press the annot menu element that you told me to add at line 34 in openw.tcl
Louis Googl (Jun 17 2019 at 18:15):and add the ant_ed.tcl to the cmake list also
Louis Googl (Jun 17 2019 at 18:21):or just as experiment keep the skt_ed but add new value to esolint_type "annot_edtior" and put the value of auto index as annot and its value is the directory of skt_ed.tcl
Daniel Rossberg (Jun 17 2019 at 18:43):Maybe, i.e. keeping it in the skt_ed.tcl and have an Annot_editor class there and using the already existing functions for the section types.
Daniel Rossberg (Jun 17 2019 at 18:45):BTW, if you got stuck and I shall help, having a patch file with your code would be usefull ;)
Louis Googl (Jun 17 2019 at 18:47):I am searching , I am new to tcl/tk.
Louis Googl (Jun 18 2019 at 14:01):pasted image
I made the new class and the auto_mkindex recognizes it but the menu button still not working it gives an error message as if I write in the terminal "make annot "
Daniel Rossberg (Jun 18 2019 at 17:37):OK, but where is the problem?
Louis Googl (Jun 18 2019 at 18:07):mged2.patch
this is the patch and I make the call back goes to annot_editor insted of sketch editor to check if it is working the copied class seems to work nice
Louis Googl (Jun 18 2019 at 18:08):but when I press save it goes back to the sketch_editor
Louis Googl (Jun 18 2019 at 18:10):OK, but where is the problem?
the problem is with the menu I didn't know how after i name the primitive and hit apply it doesn't go to the new calss
Louis Googl (Jun 18 2019 at 18:20):pasted image this is the problem
Louis Googl (Jun 18 2019 at 19:04):Screenshot-from-2019-06-18-20-57-16.png we can see that the value of esolint_type is taken from esolint_info Screenshot-from-2019-06-18-20-58-49.png and esolint_info value is taken from get_sed which seems to be a c function registered to use in tcl correct ? Screenshot-from-2019-06-18-21-00-35.png
Daniel Rossberg (Jun 18 2019 at 19:06):If I interpret the message right, the make (or _mged_make) needs to get known the annot.
Louis Googl (Jun 18 2019 at 19:08):so my problem is to know if esolint_type is getting annot as a value and this condition will work ? if {$esolint_type == "annot"}
Louis Googl (Jun 18 2019 at 19:09):If I interpret the message right, the make (or _mged_make) needs to get known the annot.
you think this is a problem in tcl code ?
Louis Googl (Jun 18 2019 at 19:11):mged2.patch
this is the patch and I make the call back goes to annot_editor insted of sketch editor to check if it is working the copied class seems to work nice
if you can look at the patch I didn't copy the methods outside the class is there a need to do that ? it seems the two classes can use this functions.
Daniel Rossberg (Jun 18 2019 at 19:14):It could be worth to have a look at ged_make() in src/libged/make.c.
Louis Googl (Jun 18 2019 at 19:15):there is _mged_make in make_solid.tcl I will look at the booth thank you
Daniel Rossberg (Jun 18 2019 at 19:16):mged2.patch
this is the patch and I make the call back goes to annot_editor insted of sketch editor to check if it is working the copied class seems to work niceif you can look at the patch I didn't copy the methods outside the class is there a need to do that ? it seems the two classes can use this functions.
It's probably OK.
Daniel Rossberg (Jun 18 2019 at 19:18):there is _mged_make in make_solid.tcl I will look at the booth thank you
I think it uses the ged_make().
Daniel Rossberg (Jun 18 2019 at 19:19):What's the status of the vlist bounding box function?
Louis Googl (Jun 18 2019 at 19:20):What's the status of the vlist bounding box function?
I should have done it yesterday but I was trying to get a result in annot_editor I will send you the patch today in the night
Louis Googl (Jun 18 2019 at 22:32):second.patch
I made this changes, in this case no need to pass the solid , and if we didn't want to log any thing in bbox() function we can move the loop to the bbox_internal() function .
Louis Googl (Jun 18 2019 at 22:53):also for the error capturing it may be done inside the calling function or inside the new bbox() function.
Louis Googl (Jun 19 2019 at 18:14):now the menu button works correctly and goes to annot in make command but it construct an empty annotation
Louis Googl (Jun 19 2019 at 18:15):I discovered that puts command in tcl prints on the mged command window
Louis Googl (Jun 19 2019 at 18:15):and now there is error in importing the annotation it seems like it is assuming that it is a sketch pasted image
Louis Googl (Jun 19 2019 at 18:18):now the menu button works correctly and goes to annot in make command but it construct an empty annotation
make1.c.patch
this is the changes I made on make.c
Daniel Rossberg (Jun 19 2019 at 18:24):There is still a lot of "sketch" in your annotation code.
Louis Googl (Jun 19 2019 at 18:25):I discovered that puts command in tcl prints on the mged command window
can you advise a more efficient way to debug tcl scripts in run time ?
Louis Googl (Jun 19 2019 at 18:25):There is still a lot of "sketch" in your annotation code.
I know now is the time to clean the copied class.
Daniel Rossberg (Jun 19 2019 at 18:33):There is still a lot of "sketch" in your annotation code.
I know now is the time to clean the copied class.
The error message you posted last was about a sketch/annot mismatch, therefore ...
Daniel Rossberg (Jun 19 2019 at 18:49):second.patch
I made this changes, in this case no need to pass the solid , and if we didn't want to log any thing in bbox() function we can move the loop to the bbox_internal() function .
The bounding box still don't return unknown commands, but logs them, what it shouldn't do (but the calling function). And, there is still the issue with the vlist length. See https://brlcad.zulipchat.com/#narrow/stream/111975-Google-Summer.20of.20Code/topic/Annotations/near/168262880
Louis Googl (Jun 19 2019 at 21:09):okay for returning the unknown commands but for the length what is the problem ? it returns the length correctly to dodraw.c but in display_list didn't care about the length from the first place.
Sean (Jun 20 2019 at 02:09):@Louis Googl can you share what your vlist bbox function currently looks like?
Louis Googl (Jun 20 2019 at 02:10):second.patch
I made this changes, in this case no need to pass the solid , and if we didn't want to log any thing in bbox() function we can move the loop to the bbox_internal() function .
@Sean
Louis Googl (Jun 20 2019 at 02:11):this is the patch contains the function and changes on dodraw and display_list but it is not final
Louis Googl (Jun 20 2019 at 02:18):pasted image
I manged to run the new class annot_editor but I have an error when saving the annotation
Louis Googl (Jun 20 2019 at 02:21):pasted image
this error is because the annotation is not like the sketch doesn't have an A and B vectors to define its plane but when I delete theme from annot_editor class and from the method write_annot_to_db the hall class fails to start
Sean (Jun 20 2019 at 02:24):to be honest, I think the tcl/tk gui work should stop -- that's a massive snake pit
Sean (Jun 20 2019 at 02:25):and anything not in C/C++ is going to need to be re-implemented in our new GUI
Sean (Jun 20 2019 at 02:26):it's not that you couldn't make something useful, you might -- but it'll probably take weeks of effort and still be half-baked. if you've never done tcl/tk before, that's a lot to bite off given your programming experience.
Louis Googl (Jun 20 2019 at 02:28):its my first time using tcl/tk but i am learning fast . what you propose ?
Sean (Jun 20 2019 at 02:28):I think you should focus on that vlist bbox function or, if you truly are stuck, that we should take a step back and establish a different set of goals going forward that are going to be more immediately achievable and useful.
Louis Googl (Jun 20 2019 at 02:31):I don't think I am very stuck , after I succeed in saving the annotation I can add the text segment to tcl and get a full described annotation from the editor . but if you think that tk gui will not be useful I could do some thing for the new gui ?
Sean (Jun 20 2019 at 02:32):stuck on the vlist bbox function
Sean (Jun 20 2019 at 02:32):i wasn't suggesting you were stuck on the tcl/tk code
Louis Googl (Jun 20 2019 at 02:35):No , I am not stuck in it. I was just focusing on the editor. I will submit a final patch today contains Mr. Daniel's suggested modifications
Sean (Jun 20 2019 at 02:35):if you're working on the tcl/tk code, you're not making progress on the C side, or at least not putting in as much time and effort. if it's complete, then you should probably take steps to prove it before moving on to something new. having 10 tasks 75% complete means you will have made 0% useful progress.
Sean (Jun 20 2019 at 02:36):the problem with the tcl/tk task is that while you might make something useful, it's pointless until the other critical pieces are working like simply displaying a label in the top-left or bottom-right.
Sean (Jun 20 2019 at 02:40):once you think you have it working, I suggest shifting gears towards vlist unit testing so you can demonstrate whether the function is behaving as expected for all possible inputs.
Sean (Jun 20 2019 at 02:42):there are lots of excellent examples of unit testing in src/libbn/tests and src/libbu/tests, so there's lot of excellent examples to follow. I suggest starting with JUST the first function in the implementation, bn_vlist_cmd_cnt(). make a patch that just adds testing for it that makes sure the function is well-behaved. make sure the test is run when you run "make unit" or "make test", passes when it should pass, fails when it should fail, and otherwise tests a broad range of possible inputs (including NULL, non-null but zero-length, one value, etc)
Sean (Jun 20 2019 at 02:43):you'll need to modify the corresponding CMakeLists.txt in src/libbn/tests to add your new test. double-check, triple-check the file you add. keep it simple and correct.
Sean (Jun 20 2019 at 02:47):the src/libbn/tests/poly_* units are somewhat better examples to follow in libbn, src/libbu/tests/str* are even simpler and good examples to consider mimicking.
Louis Googl (Jun 20 2019 at 02:49):very good I will start in this direction thank you very much .
Sean (Jun 20 2019 at 02:56):if you've never implemented a unit test before, you're basically writing a tiny program that tests just one function. there are tons of articles on the web for what makes for a good and bad unit test, but the gist is making a simple program that reliably, quickly, and simply verifies a function is behaving exactly as it should for all possible main categories of inputs, good and bad, likely or unlikely, and without any human intervention.
Sean (Jun 20 2019 at 02:57):do not expand scope to unit testing frameworks or other distractions. just a simple program like the others I mentioned. ;)
Louis Googl (Jun 20 2019 at 04:43):third.patch
@Daniel Rossberg I think this is better
Daniel Rossberg (Jun 20 2019 at 16:07):third.patch
Daniel Rossberg I think this is better
It is :) However, before we can start polishing it, I see two issues you had to fix first:
* Initialize cmd.
* Because not every caller is interested in the length, it would be a good idea to allow NULL for this parameter. You can do this by using a local len variable first, and then if (length) *length = len;.
Sean (Jun 20 2019 at 19:10):Progress @Louis Googl ?
Sean (Jun 20 2019 at 19:10):No pressure, just honestly curious ;)
Louis Googl (Jun 20 2019 at 19:15):@Sean in tcl the same situation, I send the patch for bbox yesterday , there is the problem that not every caller needs to know about the length of the vlist .
Louis Googl (Jun 20 2019 at 19:25):pasted image
this error is because the annotation is not like the sketch doesn't have an A and B vectors to define its plane but when I delete theme from annot_editor class and from the method write_annot_to_db the hall class fails to start
@Daniel Rossberg what do you think about this ?
Louis Googl (Jun 20 2019 at 20:03):forth.patch
@Daniel Rossberg
Louis Googl (Jun 20 2019 at 20:53):pasted image the annotation is saved correctly
Louis Googl (Jun 20 2019 at 20:55):but it is not drawn on the graphical window
Louis Googl (Jun 21 2019 at 00:19):I found the problem of drawing the annotation , it is because of the coordinates are to big and the vlist cmd[0] is not 15 and the there is no reference point . pasted image
Louis Googl (Jun 21 2019 at 00:54):in annot_editor there is no positive y coordinates unlike the sketch_editor :slight_smile:
Daniel Rossberg (Jun 21 2019 at 16:50):forth.patch
Daniel Rossberg
Better, but why is there a disp_mode in src/libged/display_list.c?
Daniel Rossberg (Jun 21 2019 at 17:22):in annot_editor there is no positive y coordinates unlike the sketch_editor :slight_smile:
??? What's your point with the y coordinate? On the screen, you have x and y coordinates, positive and negative, with the reference point at (0, 0).
Sure, the annotation is similar to the sketch, but they aren't the same. You have to consider the differences. But, why are the coordinates so big?
Louis Googl (Jun 21 2019 at 22:23):forth.patch
Daniel RossbergBetter, but why is there a disp_mode in src/libged/display_list.c?
this patch cleaned and tested final1.patch
Daniel Rossberg (Jun 22 2019 at 18:12):forth.patch
Daniel RossbergBetter, but why is there a disp_mode in src/libged/display_list.c?
this patch cleaned and tested final1.patch
This looks good and is ready for polishing. I.e., you can create a patch task on SourceForge for it.
Please, have especially a look at the spaces. You changed e.g. a "point_t bmin" to "point_t bmin", and there are trailing spaces.
BTW, was this everything you did yesterday?
Louis Googl (Jun 22 2019 at 20:00):No i managed to draw annotation created by the editor in the graphic window and i was trying to make the first point picked by the user stored in V like the annotation entered by in command
Louis Googl (Jun 22 2019 at 20:01):And i am trying to make a text segment in tcl
Louis Googl (Jun 22 2019 at 20:01):But the progress is slow
Louis Googl (Jun 22 2019 at 20:26):pasted image I have the following problems the line created by the editor hase three points in the vl first two are the same but the don't appear in the points in the vlist.
Louis Googl (Jun 22 2019 at 20:29):pasted image and as you can see the y is always negative unlike the sketch_editor which is weird because they are the same I didn't adjust any thing related to coordinates
Louis Googl (Jun 22 2019 at 20:32):(deleted)
Louis Googl (Jun 22 2019 at 20:45):pasted image and I am trying to update my development log the wiki is not working what is the problem?
Louis Googl (Jun 22 2019 at 22:38):pasted image
as you can see the line drawn by the editor doesn't map to the same coordinates as the one created by in command.
Louis Googl (Jun 22 2019 at 22:48):I think also we have to make a way to assign the point to be annotated
Louis Googl (Jun 22 2019 at 23:37):pasted image
as you can see the line drawn by the editor doesn't map to the same coordinates as the one created by in command.
Louis Googl (Jun 23 2019 at 03:45):now after searching and thinking the annotated point should be entered manually also the reference point I.e. or text placement point and the leader line should be added automatically.
Daniel Rossberg (Jun 23 2019 at 16:09):pasted image
as you can see the line drawn by the editor doesn't map to the same coordinates as the one created by in command.
The coordinate of the annotated point in the display coordinate system is (0, 0). I.e., I you don't have a (0, 0) in your vertex list, you cant draw a line to the annotated point.
Daniel Rossberg (Jun 23 2019 at 16:20):pasted image I have the following problems the line created by the editor hase three points in the vl first two are the same but the don't appear in the points in the vlist.
This could be a flaw in the sketch editor. It looks like the sketch editor doesn't test for duplicate coordinates in the vertex list.
Louis Googl (Jun 23 2019 at 16:22):pasted image
as you can see the line drawn by the editor doesn't map to the same coordinates as the one created by in command.The coordinate of the annotated point in the display coordinate system is (0, 0). I.e., I you don't have a (0, 0) in your vertex list, you cant draw a line to the annotated point.
so I have to reserve a point for the annotated point? which will be 0,0 ? can you explain more?
Louis Googl (Jun 23 2019 at 16:23):and what is going on with the wiki? I can't open my development log.
Daniel Rossberg (Jun 23 2019 at 16:27):pasted image and as you can see the y is always negative unlike the sketch_editor which is weird because they are the same I didn't adjust any thing related to coordinates
The draw area is a bit odd adjusted. You can correct this with the arrows at the scroll bars and the zoom buttons.
Daniel Rossberg (Jun 23 2019 at 16:32):so I have to reserve a point for the annotated point? which will be 0,0 ? can you explain more?
You do not have to, but if you want a line end point at the annotated point, its coordinate is (0, 0). V (20 20 20) means, that the origin (i.e. (0, 0)) of the following display coordinates matches with (20, 20, 20) in the world.
Daniel Rossberg (Jun 23 2019 at 16:32):and what is going on with the wiki? I can't open my development log.
No idea.
Louis Googl (Jun 23 2019 at 16:47):(deleted)
Louis Googl (Jun 23 2019 at 16:50):and what is going on with the wiki? I can't open my development log.
No idea.
the whole wiki is down
Louis Googl (Jun 24 2019 at 19:35):pasted image I am sorry for being too slow I have made these changes to allow the user to store the annotated point in V
Louis Googl (Jun 24 2019 at 19:36):now I am working on the text segment and the leader line
Louis Googl (Jun 25 2019 at 03:04):
Louis Googl (Jun 25 2019 at 03:04):do I have to make a new dev_log or it will work again?
Daniel Rossberg (Jun 25 2019 at 07:04):do I have to make a new dev_log or it will work again?
I should work now. (see https://brlcad.zulipchat.com/#narrow/stream/104062-general/topic/BRL-CAD.20website)
Daniel Rossberg (Jun 25 2019 at 16:59):pasted image I am sorry for being too slow I have made these changes to allow the user to store the annotated point in V
Shouldn't the text be on the Create tab? Why is there an extra x and y for the text? And, the annotated point could get an own tab.
However, how is your work on the bugfixes going on? I'm waiting for your patch with the bounding box function. And, there are more issues you should fix.
Louis Googl (Jun 25 2019 at 22:03):we can make whatever we want in the GUI case, the patch is ready but I am reviewing the white spaces, the extra x and y are for the text placement.
Louis Googl (Jun 25 2019 at 22:05):I have an exam on the 9th of July can I do it?
Louis Googl (Jun 25 2019 at 22:06):we can make whatever we want in the GUI case, the patch is ready but I am reviewing the white spaces, the extra x and y are for the text placement.
the important thing now is to make the text segment as it was in the in command
Louis Googl (Jun 25 2019 at 23:18):@Daniel Rossberg can you give me a list of the issues to fix or lead me where to find them?
Louis Googl (Jun 25 2019 at 23:19):is there a need to submit a patch for changes in make.c ?
Louis Googl (Jun 25 2019 at 23:21):@Daniel Rossberg is there a need to make a unit test for the bbox() function?
Louis Googl (Jun 26 2019 at 03:05):
Louis Googl (Jun 26 2019 at 03:05):I am working on making a method for creating the text segment
Daniel Rossberg (Jun 26 2019 at 06:37):I have an exam on the 9th of July can I do it?
Sure, thanks for letting us know.
Daniel Rossberg (Jun 26 2019 at 06:40):Daniel Rossberg can you give me a list of the issues to fix or lead me where to find them?
Sure, I could tell you some. But it would be better if you would find them by yourself.
Daniel Rossberg (Jun 26 2019 at 06:43):Daniel Rossberg is there a need to make a unit test for the bbox() function?
In general I would say, it would be nice to have one. In your case, I say you shall definitely write one, because you seem to not test enough :wink:
There are still some very unpleasant flaws in the annotation. Simple tests should unveil them.
Daniel Rossberg (Jun 26 2019 at 06:44):Play a bit with the creation and display of the annotations.
Daniel Rossberg (Jun 26 2019 at 06:49):is there a need to submit a patch for changes in make.c ?
Are they necessary to make it work?
You can (should) split patches if they can be seen independently. I.e., the make doesn't depend on the annotation editor, but the annotation editor depens on make.
Louis Googl (Jun 26 2019 at 14:58):is there a need to submit a patch for changes in make.c ?
Are they necessary to make it work?
You can (should) split patches if they can be seen independently. I.e., the make doesn't depend on the annotation editor, but the annotation editor depens on make.
the make.c patch introduces the annotation to make and the editor doesn't work without it.
Daniel Rossberg (Jun 26 2019 at 18:34):The loop for sp->s_vlen is now in bn_vlist_bbox(). Why not passing it there?
I just realized, that not only one indent is wrong in bn_vlist_bbox() but almost all.
Louis Googl (Jun 26 2019 at 20:49):If you feel it's better i can do it but it is the same
Louis Googl (Jun 27 2019 at 00:13):I am working on unit test
Louis Googl (Jun 27 2019 at 00:29):there are lots of excellent examples of unit testing in src/libbn/tests and src/libbu/tests, so there's lot of excellent examples to follow. I suggest starting with JUST the first function in the implementation, bn_vlist_cmd_cnt(). make a patch that just adds testing for it that makes sure the function is well-behaved. make sure the test is run when you run "make unit" or "make test", passes when it should pass, fails when it should fail, and otherwise tests a broad range of possible inputs (including NULL, non-null but zero-length, one value, etc)
@Sean I was looking to the function bn_vlist_cmd_cent() it doesn't use the function I wrote, I is probably better to make the test for
bn_vlist_bbox() correct?
Louis Googl (Jun 27 2019 at 00:41):and who provide the inputs for the test?
Louis Googl (Jun 27 2019 at 00:46):and who provide the inputs for the test?
i found the answer they are in cmak.txt file
Sean (Jun 27 2019 at 03:51):@Louis Googl the inputs can be in the test file itself or in the cmakelists file -- we have tests that do it both ways. however, they are typically better in the test itself to keep it fully encapsulated. that's why I mentioned src/libbn/tests/poly_* and src/libbu/tests/str* as good examples to mimic... did you not read them?
Sean (Jun 27 2019 at 03:55):Sean I was looking to the function bn_vlist_cmd_cent() it doesn't use the function I wrote, I is probably better to make the test for
bn_vlist_bbox() correct?
I intentionally suggested a far simpler function to test first. If you can't create a proper unit test for it in less than an hour, you have some critical learning to do, mistakes will be made.
Sean (Jun 27 2019 at 03:56):you should be able to create a decent unit test for it simply by reading the header in include/bn/vlist.h
Louis Googl (Jun 27 2019 at 16:23):Louis Googl the inputs can be in the test file itself or in the cmakelists file -- we have tests that do it both ways. however, they are typically better in the test itself to keep it fully encapsulated. that's why I mentioned src/libbn/tests/poly_* and src/libbu/tests/str* as good examples to mimic... did you not read them?
Yes I have read them I am working on it ,
Louis Googl (Jun 28 2019 at 02:01):I added the file that I will use for the test to the CMake build system and learned how to add test to CMake file, now I am writing the test program but I am having a truble inventing the list. all the list I have dealt with appears from nowhere.
Sean (Jun 28 2019 at 04:40):what do you mean @Louis Googl ? lists appears from nowhere? You mean the criteria for validation?
Louis Googl (Jun 28 2019 at 17:08):@Sean I found out the mistake thank you
Louis Googl (Jun 28 2019 at 17:08):pasted image this is my test
Louis Googl (Jun 28 2019 at 17:11):pasted image and this is the code for
zcmd_cnt .c
Louis Googl (Jun 28 2019 at 17:58):Now the pass criteria and i have to find out if my test is working
Sean (Jun 28 2019 at 18:18):@Louis Googl glad to see you figured it out! good job.
You'll want to tidy up a lot of details, but you're on the right track. Some details to fix once AFTER you are sure it's working is 1) you only need to pass and read 1 arg from cmake, not 2 (e.g., you don't use 'length'), 2) the name of your test and test file are inconsistent with the rest of the tests, 3) the documentation/comments you put in the cmakelists file belong in the .c file (or can at least be considerably more brief), and 4) to add more types of tests like your comment says it's doing.
Louis Googl (Jun 28 2019 at 18:22):Thanks i am sorry for being slow , for the argv it's obvious it's not necessary to use tow but the use of length is correct?
Louis Googl (Jun 28 2019 at 18:23):What should i name the file? Vlist or bn_vlist_cmd
Louis Googl (Jun 28 2019 at 18:24):bn_vlist_cmd_cnt
Sean (Jun 28 2019 at 18:49):Thanks i am sorry for being slow , for the argv it's obvious it's not necessary to use tow but the use of length is correct?
Sorry, miswrote -- yes you do use it, but you don't need to use it -- arguably you don't want to use it. All that parameter is doing is controlling how many times BN_ADD_VLIST is called and that's not really testing different cases. Unit tests should test was many different kinds of distinct and edge cases as possible, not necessarily multiples unless we believe that we'll likely see different behavior in adding 10 vs 100 vs 10000 elements.
More interesting is probably going to be crafting different kinds of lists manually -- a null list, 1 element added, 10 added, 1 added 1 removed, 2 added 3 removed, 2 added 1 removed 1 added, etc. plus adding different kind of vlist elements if possible, adding vlists with good data, vlists with bad data, ... hopefully you get the idea.
Sean (Jun 28 2019 at 18:50):[Quoting…]
Should name it like the other files. Look at the examples. Notice the pattern. Go for a simple as it needs to be until you have an excuse to make it less simple.
Louis Googl (Jun 28 2019 at 21:57):Thanks i am sorry for being slow , for the argv it's obvious it's not necessary to use tow but the use of length is correct?
Sorry, miswrote -- yes you do use it, but you don't need to use it -- arguably you don't want to use it. All that parameter is doing is controlling how many times BN_ADD_VLIST is called and that's not really testing different cases. Unit tests should test was many different kinds of distinct and edge cases as possible, not necessarily multiples unless we believe that we'll likely see different behavior in adding 10 vs 100 vs 10000 elements.
More interesting is probably going to be crafting different kinds of lists manually -- a null list, 1 element added, 10 added, 1 added 1 removed, 2 added 3 removed, 2 added 1 removed 1 added, etc. plus adding different kind of vlist elements if possible, adding vlists with good data, vlists with bad data, ... hopefully you get the idea.
I think I didn't get you perfectly, we are testing a function which returns the number of commands in a vlist, the only important thing is whether the returned number is correct. after adding a test for the null case and creat the case of removing some element from the list it dosesn't matter if the list contains an annotation or a sphere correct? if we want to do that can we construct some arbitrary solid inside the test code ? or just copy the list and store it inside the test file?
Louis Googl (Jun 29 2019 at 00:27):pasted image the test works
Louis Googl (Jun 29 2019 at 00:30):pasted image but I have a problem when using RT_ADD_VLIST because of RTG, it is defined in global.h
Louis Googl (Jun 29 2019 at 00:50):pasted image the test works
this run is by running bu_test with the appropriate cmd parameters I.e( zcmd_cnt 5 5 ) is it enough to assure that it is working?
Louis Googl (Jun 29 2019 at 01:00):pasted image but I have a problem when using RT_ADD_VLIST because of RTG, it is defined in global.h
I tried to define RTG in my test file the build succeeded but I had this error when executing, it is inside BN_ADD_VLIST I don't know if it is because of my wrong fix or something else. need help pasted image
Louis Googl (Jun 29 2019 at 01:02):I think if the file was in librt I wouldn't have the link problem because RT_ADD_VLIST works fine there
Louis Googl (Jun 29 2019 at 01:04):I tried to make the same in vlist.c and had the same link problem
Louis Googl (Jun 30 2019 at 18:59):@Sean I am constructing an annotation inside my test program and will call ant_to_vlist from there and take the vlist is this a good solution?
Louis Googl (Jun 30 2019 at 19:14):there is another way is to write a function inside annot.c and call it from the test program.
Louis Googl (Jun 30 2019 at 19:51):there is another way is to write a function inside annot.c and call it from the test program.
also didn't work the function I wrote became the unresolved external :hurt:
Louis Googl (Jul 01 2019 at 14:41):@Daniel Rossberg @Sean @Shubham Rathore any help pleas.
Daniel Rossberg (Jul 01 2019 at 18:19):??? I don't know what wrote and what the problem is.
Louis Googl (Jul 01 2019 at 18:30):The problem is when using RT_ADD_VLIST there is linking error with RTG object you can see it in previous pictures RT_ADD_VLIST works fine in annot.c and other files in librt but doesn't work in vlist.c and my test program which exists in libbn
Daniel Rossberg (Jul 01 2019 at 18:37):Show me your code! (Do you remember? :wink: )
Daniel Rossberg (Jul 01 2019 at 18:38):The patch file thing, you know ;)
Louis Googl (Jul 01 2019 at 18:54):zcmd_cnt.c it is not a batch it is the new file I made for the unit test
Louis Googl (Jul 01 2019 at 18:59):it runs when I run bn_test and I have add it to the cmakelist file and put the test commands but the problem now is to make a list to send it to bn_vlist_cmd_cnt() which I will do it using RT_ADD_VLIST and that give us the error of RTG external object linking error
Daniel Rossberg (Jul 01 2019 at 20:59):When you build your test, do you add librt to the linked libraries in the CMakeLists.txt configuration?
Louis Googl (Jul 01 2019 at 21:30):NO, I don't know how to do that , I know this is the cause of the error but I didn't know where to add it , because in cmakelist I found that it mentions the include and the source files only I didn't fined any mention to linked libraries .
Louis Googl (Jul 01 2019 at 23:08):# Include directories needed by librt users
set(RT_INCLUDE_DIRS
${BRLCAD_BINARY_DIR}/include
${BRLCAD_SOURCE_DIR}/include
${BU_INCLUDE_DIRS}
${BN_INCLUDE_DIRS}
${BG_INCLUDE_DIRS}
${NMG_INCLUDE_DIRS}
${BREP_INCLUDE_DIRS}
${P2T_INCLUDE_DIR}
${OPENNURBS_INCLUDE_DIRS}
)
I added this but it didn't work
BRLCAD_LIB_INCLUDE_DIRS(rt RT_INCLUDE_DIRS RT_LOCAL_INCLUDE_DIRS)
Louis Googl (Jul 02 2019 at 01:51):set(BRLCAD_LIBS
librt
)
foreach(blib ${BRLCAD_LIBS})
foreach(CFG_TYPE ${CMAKE_CONFIGURATION_TYPES})
string(TOUPPER "${CFG_TYPE}" CFG_TYPE_UPPER)
configure_file(${BRLCAD_ROOT_DIR}/bin/${blib}.dll ${CMAKE_CURRENT_BINARY_DIR}/${CFG_TYPE}/${blib}.dll COPYONLY)
endforeach(CFG_TYPE ${CMAKE_CONFIGURATION_TYPES})
configure_file(${BRLCAD_ROOT_DIR}/bin/${blib}.dll ${CMAKE_CURRENT_BINARY_DIR}/${blib}.dll COPYONLY)
BRLCAD_LIB_INCLUDE_DIRS(rt RT_INCLUDE_DIRS RT_LOCAL_INCLUDE_DIRS)
Daniel Rossberg (Jul 02 2019 at 17:27):I'm still waiting for your patch file. The solution is probably in the CMakeLists.txt configuration file, and I want to see how yours looks like. It's important to provide patches with the complete code!!!
I know that it has at least the linking issue, but only with this at hand I can point you to the solution.
Louis Googl (Jul 02 2019 at 18:23): Louis Googl (Jul 02 2019 at 18:24):sorry I thought you want the code of the test function
Louis Googl (Jul 02 2019 at 18:46):CMakeLists.txt.patch
@Daniel Rossberg forget the first one.
Daniel Rossberg (Jul 02 2019 at 19:32):Unfortunately, this is still not the whole set of your changes to the source code. You even changed annot.c. But well, the linking works for me with this one: test.patch
Louis Googl (Jul 02 2019 at 19:48):the change in annot.c is just a function do what the loop does in the zcmd_cnt
Louis Googl (Jul 02 2019 at 19:50):an.patch nothing important
Louis Googl (Jul 02 2019 at 19:50):Unfortunately, this is still not the whole set of your changes to the source code. You even changed annot.c. But well, the linking works for me with this one: test.patch
thank you very much
Louis Googl (Jul 03 2019 at 00:30):(deleted)
Louis Googl (Jul 03 2019 at 00:32):(deleted)
Louis Googl (Jul 03 2019 at 00:32):(deleted)
Louis Googl (Jul 03 2019 at 03:14):pasted image
It didn't work the same error
Louis Googl (Jul 03 2019 at 03:15):pasted image
the function in annot.c also make this error the same error which happened when I defined rt_g inside the test file
Louis Googl (Jul 03 2019 at 03:16):@Daniel Rossberg I added libbu also but it didn't work also
Louis Googl (Jul 03 2019 at 03:30):
Louis Googl (Jul 03 2019 at 03:45):I found the solution by adding two lines to the test program code without linking any library
struct rt_g RTG ;
BU_LIST_INIT(&RTG.rtg_vlfree); :hurt:
Louis Googl (Jul 03 2019 at 03:54):zcmd_cnt.c.patch no there is no need to use the function in annot.c
Louis Googl (Jul 03 2019 at 03:55):tomorrow I will work on the test cases and the name of the test file and test commands
Daniel Rossberg (Jul 03 2019 at 18:07):zcmd_cnt.c.patch no there is no need to use the function in annot.c
Hmm, the patch is incomplete again (it contains the new file only).
However, maybe you can turn this to an advantage: The vlist is a bn construct, RT_ADD_VLIST() is in fact BN_ADD_VLIST(), etc.. I.e., the whole test should be feasible without the help of librt.
Louis Googl (Jul 03 2019 at 19:08):I just send it to show you the change it works now
Louis Googl (Jul 04 2019 at 00:56):tests.patch
@Sean @Daniel Rossberg this is the test. any notes ?
Daniel Rossberg (Jul 04 2019 at 18:30):After all your difficulties, I'm positively surprised that you wrote a nice, "simple" test function. Keep this in mind when you perfect it.
Therefore, this are my findings:
Louis Googl (Jul 04 2019 at 22:21):thank you, the includes are not necessary I will change them, for bn_vlist_main() it is generated automatically when configuring the project with cmake it is generated inside bn_test.c so it is generated from cmake into the build file because of that svn is not seeing it as a change in the source code pasted image
Louis Googl (Jul 04 2019 at 23:18):tests1.patch @Daniel Rossberg
Louis Googl (Jul 04 2019 at 23:23):is it good now to submit to SourceForge?
Louis Googl (Jul 04 2019 at 23:23):@Daniel Rossberg @Sean @Shubham Rathore I think it is better if we revised the scope of the project as Mr. Daniel suggested in the evaluation because I am struggling with Tcl scripts and it will not be used in the new Gui what you suggest?
Louis Googl (Jul 05 2019 at 01:38):I noticed that the position flags doesn't do anything the annotation is always in a top left position, I tried to make an example of the bottom right is this the way we want it to be ? pasted image
Shubham Rathore (Jul 05 2019 at 04:43):Annotations are referenced solely by the point V in the 3D space, the position is in relation to this particular V. The default position is TL as of now. While adding support for all the relative positions you'll have to consider some factors, like the spacing between the bounding box lines and the leader line. Could you please share the patch that you used to generate the result shown in the image.
Daniel Rossberg (Jul 05 2019 at 18:02):I noticed that the position flags doesn't do anything the annotation is always in a top left position, I tried to make an example of the bottom right is this the way we want it to be ? pasted image
Yes, this is one of the bugs. The point which shall be at the "top-right" or "middle-left" etc. is the txt_seg.ref_pt (i.e. in the text segment structure). Can you debug this in Visual Studio? Any idea how to fix this?
Daniel Rossberg (Jul 05 2019 at 18:36):is it good now to submit to SourceForge?
Not yet. The main issue is a compilation warning/error because of the unused variable mybnlist. Other findings are:
* There are many empty lines before and after the includes in bn_vlist.c. Are they really necessary? It looks like 1 or 2 lines are usual.
* #include "rt/global.h", struct rt_g RTG ; and BU_LIST_INIT(&RTG.rtg_vlfree); shouldn't be necessary any more. RTG is generally unused.
* There are a lot of lines which contain only spaces in bn_vlist.c. An empty line shouldn't contain additional spaces. There is an option in Visual Studio to visualize the space characters.
* The source files shall end with a new-line.
* One empty line between the two bn_test blocks is enough in CMakeLists.txt.
Louis Googl (Jul 05 2019 at 21:18):Annotations are referenced solely by the point V in the 3D space, the position is in relation to this particular V. The default position is TL as of now. While adding support for all the relative positions you'll have to consider some factors, like the spacing between the bounding box lines and the leader line. Could you please share the patch that you used to generate the result shown in the image.
@Shubham Rathore there is no batch this is hard coded by changing the y in bn_vlist_2string() my point is to ask how you think bottom right should looks like
Louis Googl (Jul 05 2019 at 21:20):I.e changing the y coordinate of the text_seg.ref_pt
Louis Googl (Jul 05 2019 at 21:22):I noticed that the position flags doesn't do anything the annotation is always in a top left position, I tried to make an example of the bottom right is this the way we want it to be ? pasted image
Yes, this is one of the bugs. The point which shall be at the "top-right" or "middle-left" etc. is the txt_seg.ref_pt (i.e. in the text segment structure). Can you debug this in Visual Studio? Any idea how to fix this?
@Daniel Rossberg yes I will debug it and suggest a solution tomorrow
Louis Googl (Jul 05 2019 at 21:31):is it good now to submit to SourceForge?
Not yet. The main issue is a compilation warning/error because of the unused variable mybnlist. Other findings are:
* There are many empty lines before and after the includes in bn_vlist.c. Are they really necessary? It looks like 1 or 2 lines are usual.
*#include "rt/global.h",struct rt_g RTG ;andBU_LIST_INIT(&RTG.rtg_vlfree);shouldn't be necessary any more. RTG is generally unused.
* There are a lot of lines which contain only spaces in bn_vlist.c. An empty line shouldn't contain additional spaces. There is an option in Visual Studio to visualize the space characters.
* The source files shall end with a new-line.
* One empty line between the two bn_test blocks is enough in CMakeLists.txt.
I will fix them all thank you. but the linking error which was RTG unresolved external is fixed only by rt_g RTG; and the BU_assert error is fixed by BU_LIST_INIT(&RTG.rtg_vlfree) why do you think they are not necessary? you can see in the global.h line 53
/**
* Applications that are going to use RT_ADD_VLIST and RT_GET_VLIST
* are required to execute this macro once, first:
*
* BU_LIST_INIT(&RTG.rtg_vlfree);
*
* Note that RT_GET_VLIST and RT_FREE_VLIST are non-PARALLEL.
*/
Louis Googl (Jul 05 2019 at 21:33):@Daniel Rossberg @Shubham Rathore sorry I couldn't do anything today because I was up all day to change my sleeping schedule for the exam apparently exams in the university are done in the day period. :grinning:
Daniel Rossberg (Jul 06 2019 at 16:41):I will fix them all thank you. but the linking error which was RTG unresolved external is fixed only by rt_g RTG; and the BU_assert error is fixed by BU_LIST_INIT(&RTG.rtg_vlfree) why do you think they are not necessary? you can see in the global.h line 53
/**
- Applications that are going to use RT_ADD_VLIST and RT_GET_VLIST
are required to execute this macro once, first:
*BU_LIST_INIT(&RTG.rtg_vlfree);
*Note that RT_GET_VLIST and RT_FREE_VLIST are non-PARALLEL.
*/
Use BU_ADD_VLIST and BU_GET_VLIST :grinning_face_with_smiling_eyes:
Louis Googl (Jul 06 2019 at 23:42):I think it's not possible without rt_g RTG; because you can see that it is capsulated in RT_ADD_VLIST
pasted image
Louis Googl (Jul 06 2019 at 23:42):in this case we can delete BU_LIST_INIT(&RTG.rtg_vlfree);
Louis Googl (Jul 06 2019 at 23:47):annot.c.patch
I made this first approach to the position problem It is not correct and it is not working but this the type of solution I am thinking of, what do you say? and this works for the bottom right only in case of center I think the dimensions of all the label should be calculated
Louis Googl (Jul 06 2019 at 23:50):all this logic will exist in a separate function and it will be called here in ant_to_vlist before calling seg_to_vlist, or you think we can put it in seg_to_vlist after the segment is determined as a text segment and modify the ref_point there?
Louis Googl (Jul 06 2019 at 23:56):and I have something to ask about BU_STR_EQUAL is not giving the expected results I can see while debugging that both strings are the same but it returns 0 I don't know why. any Idea?
Daniel Rossberg (Jul 07 2019 at 17:56):in this case we can delete BU_LIST_INIT(&RTG.rtg_vlfree);
What do you want to say here? You have to use RTG but uninitialized?
Daniel Rossberg (Jul 07 2019 at 17:58):What's the problem with a BU_LIST_INIT(&vlfree); and then BU_ADD_VLIST(&vlfree, &head, ptzero, BN_VLIST_LINE_MOVE);?
Daniel Rossberg (Jul 07 2019 at 18:21):and I have something to ask about BU_STR_EQUAL is not giving the expected results I can see while debugging that both strings are the same but it returns 0 I don't know why. any Idea?
shouldn't rel_pos be of type char* ? And BU_STR_EQUAL(rel_pos, "bottom right")?
Daniel Rossberg (Jul 07 2019 at 18:23):But, why don't you check tsg->pt_rel_pos directly?
Daniel Rossberg (Jul 07 2019 at 18:24):annot.c.patch
I made this first approach to the position problem It is not correct and it is not working but this the type of solution I am thinking of, what do you say? and this works for the bottom right only in case of center I think the dimensions of all the label should be calculated
Your patch contains a lot of lines where you changed the white spaces only. This makes it hard to read.
Louis Googl (Jul 07 2019 at 23:14):annot1.c.patch
this one works and get the wanted result and works for the capital and lower case letters
Louis Googl (Jul 08 2019 at 22:32):pasted image
this is the bottom left case I don't see the need for these positions but what you think we should do in this case
Daniel Rossberg (Jul 09 2019 at 02:14):Looks like top right to me?
Louis Googl (Jul 09 2019 at 22:30):the whole text is on the left of the reference point and the bottom of it
Louis Googl (Jul 09 2019 at 22:56):
Louis Googl (Jul 11 2019 at 17:00):sorry I didn't do anything in the past two days because of the exam on the 9th and yesterday I was sick
Louis Googl (Jul 11 2019 at 17:01):pasted image
what do you think about this for the bottom left?
Louis Googl (Jul 11 2019 at 17:02):@Shubham Rathore @Daniel Rossberg
Louis Googl (Jul 11 2019 at 17:14): Daniel Rossberg (Jul 11 2019 at 17:15):I remember these position flags different, but I have to check. Maybe @Shubham Rathore knows more. (He should ;)
Louis Googl (Jul 11 2019 at 17:16):I made a function to calculate the length of the label you can see it in the patch
Louis Googl (Jul 11 2019 at 17:17):I will try to finish all the cases today and start cleaning the patch
Louis Googl (Jul 11 2019 at 17:18):
Shubham Rathore (Jul 12 2019 at 12:37):@Louis Googl from what I understood, you don't see the need of the placement flags here ! ....Okay, so first of all, we are currently only dealing with simple leader lines. The flags indicate the position wrt to the ref_point, and do not portray a greater significance here, but have you thought of annotation types other than the leader lines ? For eg. linear dimensions ? I'll attach something that I found on AutoCAD wiki for you to understand. POS_TEXT.png
You can assume the ref_point to be the centre of the line. The significance of position can clearly be seen here. :)
P.S. : Please read the TODO from line 1669 onwards, you'll come to know more about the types of annotations and text properties.
Louis Googl (Jul 12 2019 at 12:46):Thank you very much i didn't mean no need to position flag i meant no need to buttom left in the case i showed in the picture
Louis Googl (Jul 12 2019 at 12:57):What do you think about the results and the patch ? @Shubham Rathore
Louis Googl (Jul 12 2019 at 18:30):pasted image
@Daniel Rossberg @Shubham Rathore what do you think ?
Louis Googl (Jul 12 2019 at 18:33):
Louis Googl (Jul 12 2019 at 18:57):
Daniel Rossberg (Jul 12 2019 at 19:02):In principle it looks good, but I still think that the position flag refers to a point of the label because this flag is a property of the label. I.e., bottom means that the reference point given in the label's text structure is at the bottom of the text, etc.
It isn't even required that a line goes to this point. This is only how the annot command does it. Any other sequence of lines, arcs, texts, etc. would be possible too.
Louis Googl (Jul 13 2019 at 21:21):annot.c.patch
this is the patch is it good for submit ?
Louis Googl (Jul 13 2019 at 21:23):In principle it looks good, but I still think that the position flag refers to a point of the label because this flag is a property of the label. I.e., bottom means that the reference point given in the label's text structure is at the bottom of the text, etc.
It isn't even required that a line goes to this point. This is only how the annot command does it. Any other sequence of lines, arcs, texts, etc. would be possible too.
maybe this will be in the case of other types of annotations like dimension line, but this is a point attached to the label which is the ref_pt
Louis Googl (Jul 14 2019 at 00:07):tests2.patch
this is final for the test program
Louis Googl (Jul 14 2019 at 22:45):pasted image you can notice here that the long annotation can't be shown even when zooming because the annotation doesn't undergo zooming do we consider this as a bug?
Louis Googl (Jul 14 2019 at 22:46):I put the long label between ""quotation marks is this a good behavior?
Louis Googl (Jul 14 2019 at 23:20):I think it should be a way to resize the label text individually ?
Louis Googl (Jul 16 2019 at 00:48):pasted image
I tried this approach for the dimension line still needs to work on a lot of things like the text. new in function and new list for input but the same annotation primitive. @Daniel Rossberg
Louis Googl (Jul 16 2019 at 00:50):what do you think?
Daniel Rossberg (Jul 16 2019 at 18:31):annot.c.patch
this is the patch is it good for submit ?
Is it? How about the indents?
Daniel Rossberg (Jul 16 2019 at 19:08):In principle it looks good, but I still think that the position flag refers to a point of the label because this flag is a property of the label. I.e., bottom means that the reference point given in the label's text structure is at the bottom of the text, etc.
It isn't even required that a line goes to this point. This is only how the annot command does it. Any other sequence of lines, arcs, texts, etc. would be possible too.
maybe this will be in the case of other types of annotations like dimension line, but this is a point attached to the label which is the ref_pt
The position flag has nothing to do with the leader line etc.. It is a property of the txt_seg structure and has to be understood in this context. I.e., there is a text, a reference point, and the position of the reference point pt_rel_pos: label.png
Daniel Rossberg (Jul 16 2019 at 19:08):How would you describe them?
Daniel Rossberg (Jul 16 2019 at 19:27):what do you think?
It looks good, but it won't work, because the line had to be in model space and its label in display space. (Try to create a dimension line to an arb8.)
Daniel Rossberg (Jul 18 2019 at 19:59):@Louis Googl Are you making progress? You haven't updated your development log since almost 2 weeks, and the next evaluation is close.
Louis Googl (Jul 20 2019 at 11:59):@Daniel Rossberg sorry I had minor surgery I couldn't do anything.
Louis Googl (Jul 20 2019 at 12:04):In principle it looks good, but I still think that the position flag refers to a point of the label because this flag is a property of the label. I.e., bottom means that the reference point given in the label's text structure is at the bottom of the text, etc.
It isn't even required that a line goes to this point. This is only how the annot command does it. Any other sequence of lines, arcs, texts, etc. would be possible too.
maybe this will be in the case of other types of annotations like dimension line, but this is a point attached to the label which is the ref_pt
The position flag has nothing to do with the leader line etc.. It is a property of the txt_seg structure and has to be understood in this context. I.e., there is a text, a reference point, and the position of the reference point pt_rel_pos: label.png
in the case of regular annotation, it happens to be the text placement point is the endpoint of the leader line what you suggest ? adding another point to the annotation in the (in) function and change the ref_pt number in the VL ?
Louis Googl (Jul 20 2019 at 12:08):annot.c.patch
this is the patch is it good for submit ?Is it? How about the indents?
I am sorry for this mistake I fell stupid because of the indents in the hacking file there are recommendations but it is not the same in the code as you can see it recommends inside the for loop a tab and two spaces pasted image
Louis Googl (Jul 20 2019 at 12:29):pasted image this what I did which is the same in make.c file
Louis Googl (Jul 20 2019 at 12:32):pasted image this from make.c
Louis Googl (Jul 20 2019 at 13:17):(deleted)
Louis Googl (Jul 20 2019 at 13:20):annot4.c.patch I hope this is better @Daniel Rossberg
Louis Googl (Jul 20 2019 at 13:27):what do you think?
It looks good, but it won't work, because the line had to be in model space and its label in display space. (Try to create a dimension line to an arb8.)
what you suggest in this case ? we need a new primitive for the dimension line? or we put the line in separate vlist with another projection matrix ?
Louis Googl (Jul 20 2019 at 14:36):pasted image
this what results for the arb
Louis Googl (Jul 20 2019 at 14:37):when zooming its ruined
Louis Googl (Jul 20 2019 at 16:06):pasted image the line works when I set the model matrix to vlist in ant_to_vlist, so now the problem is to separate the text and the line and put each one with the correct matrix
Louis Googl (Jul 20 2019 at 16:08):another thing we will have to consider later is the function which converts the text to a vlist gives horizontal text always we want to rotate it to be parallel to the line
Louis Googl (Jul 21 2019 at 15:11):pasted image i could put the lines in the model space and the label in display space but I couldn't relate them together like the real annotation with the annotated point
Louis Googl (Jul 21 2019 at 15:12):dimentionline2.c.patch @Daniel Rossberg this is the patch I hope you could tell me what I am doing wrong
Daniel Rossberg (Jul 21 2019 at 15:31):annot.c.patch
this is the patch is it good for submit ?Is it? How about the indents?
I am sorry for this mistake I fell stupid because of the indents in the hacking file there are recommendations but it is not the same in the code as you can see it recommends inside the for loop a tab and two spaces pasted image
You can set the indentation behavior of Visual Studio in its options. There you can set the indentation size to 4 spaces, the tab size to 8 spaces, etc..
Daniel Rossberg (Jul 21 2019 at 15:50):The position flag has nothing to do with the leader line etc.. It is a property of the txt_seg structure and has to be understood in this context. I.e., there is a text, a reference point, and the position of the reference point pt_rel_pos: label.png
in the case of regular annotation, it happens to be the text placement point is the endpoint of the leader line what you suggest ? adding another point to the annotation in the (in) function and change the ref_pt number in the VL ?
??? I'm talking about the txt_seg structure as it is. Please have a look at it include/rt/geom.h. This structure describes a text in an annotation (no leader line, arc, etc. !!!). This structure has a reference point called ref_pt and a flag for the relative position of this point to the text, called pt_rel_pos. I thought it's self-explanatory what top, bottom, left, right, etc. mean, but I posted here in addition an image with the (approximate) position of 8 of the 9 relative positions.
Therefore, where is the top left point in this image?
Louis Googl (Jul 21 2019 at 15:53):
Louis Googl (Jul 21 2019 at 15:54):in VL the ref_pt of the txtseg is 0 which is the text placement point entered by the user
Daniel Rossberg (Jul 21 2019 at 16:02):Regarding the dimension line:
I "suggest" that the annotation primitive in its current state can't be used for dimension lines. Which issues does it have?
Daniel Rossberg (Jul 21 2019 at 16:05):in VL the ref_pt of the txtseg is 0 which is the text placement point entered by the user
That's right and this is okay. My point is, that you seem to switch left with right, top with bottom. pt_rel_pos is a property of the text, not the line!
Louis Googl (Jul 21 2019 at 16:07):in VL the ref_pt of the txtseg is 0 which is the text placement point entered by the user
That's right and this is okay. My point is, that you seem to switch left with right, top with bottom.
pt_rel_posis a property of the text, not the line!
okay now it is clear
Louis Googl (Jul 21 2019 at 16:08):Regarding the dimension line:
I "suggest" that the annotation primitive in its current state can't be used for dimension lines. Which issues does it have?
- A dimension line would need more than one reference point in the model space.
- The txt_seg needs additional attributes, e.g. the font size or a rotation.
You may find more features missing for a dimension line.
what do you suggest? making a new primitive or make modifications on the current one?
Louis Googl (Jul 21 2019 at 16:15):for the rotation, there is a rotation matrix in bn_vlist_3string() function
Daniel Rossberg (Jul 21 2019 at 16:27):what do you suggest? making a new primitive or make modifications on the current one?
I would try to modify the existing one first. I don't consider the current annotation primitive as final.
Daniel Rossberg (Jul 21 2019 at 16:30):for the rotation, there is a rotation matrix in bn_vlist_3string() function
Sounds good. Now, the txt_seg needs an additional angle attribute, and we can make up the rotation matrix.
Louis Googl (Jul 21 2019 at 16:34):dimentionline2.c.patch Daniel Rossberg this is the patch I hope you could tell me what I am doing wrong
what do you think about this patch? i mean changing the matrix before calling seg_to_vlist for different segments
Daniel Rossberg (Jul 21 2019 at 19:54):This is based on the current state of the annotation structure and cannot work therefore. You try to guess with an unsuited criterion if it's a dimension line, but this won't help either. It won't survive zooming or rotation. This kind of "dimension line" would work even better with NMGs.
Louis Googl (Jul 22 2019 at 14:56):after manipulating the projection matrix the dimension line survived the zooming and rotation but the label didn't if I add an entier annotation it may works
Louis Googl (Jul 22 2019 at 23:13):
Louis Googl (Jul 22 2019 at 23:15):@Daniel Rossberg now it works what do you think? we can continue with this approach and modify the text segment for size and rotation?
Louis Googl (Jul 22 2019 at 23:32):@Shubham Rathore Mr. Shubham what do you think for this kind of dimension line?
Louis Googl (Jul 22 2019 at 23:38):Daniel Rossberg now it works what do you think? we can continue with this approach and modify the text segment for size and rotation?
and for 3d solids do we need to make the dimension line in 3d space? this will require changing the verts from 2d to 3d point
Louis Googl (Jul 22 2019 at 23:46):pasted image
text rotated 90 degrees
Louis Googl (Jul 23 2019 at 15:15):
Louis Googl (Jul 23 2019 at 15:17):
Louis Googl (Jul 23 2019 at 15:18):it still needs a lot of work but what do you think?
Louis Googl (Jul 23 2019 at 15:22):the text size is entered by the user and the rotation angle is calculated based on the points
Daniel Rossberg (Jul 23 2019 at 21:32):I had to look at your code and see which tricks you are doing there and how it integrates into the overall philosophy. However, it looks like you are approaching to what is needed for a dimension line.
Louis Googl (Jul 24 2019 at 14:26):@Daniel Rossberg for the first problem I changed the order of converting the segments to vlist I changed the text to display space first and then I changed the lines to model space.
Louis Googl (Jul 24 2019 at 14:28):for the size and rotation of the text, I changed the txt_seg struct but It still not passing the values the user inters to the data base I have to modify the export and import functions in annot.c correct?
Louis Googl (Jul 24 2019 at 15:48):pasted image I have modified the import and export functions to count for new attributes but when I call get It dosn't print the label or the rotation angle on mged command line window
Louis Googl (Jul 24 2019 at 15:50):I will send you a patch but it needs some time because the working version had a lot of changes from previous patches I will download a new one
Louis Googl (Jul 25 2019 at 19:47):pasted image
@Daniel Rossberg now the import and export is correct but I have this problem in the label
Louis Googl (Jul 25 2019 at 19:49):dimensionline.patch this is the patch, it needs a lot of changes to be more dynamic, what do you think about the approach?
Louis Googl (Jul 25 2019 at 19:58):@Shubham Rathore Mr. Shubham do you have an Idea why the label value is printed as result of get command in the second case but not in the annotDL case in the previous picture.
Louis Googl (Jul 25 2019 at 20:11):dimensionline1.patch
forget the first one see this
Louis Googl (Jul 25 2019 at 20:13):I think there is a better way to distinguish the regular annotation from the dimension line in the function ant_to_vlist() I considered the segments count as a start.
Louis Googl (Jul 26 2019 at 15:09):for making a dimension line for a 3d object what do you think about changing the verts in rt_annot_internal to 3d point which will work because the lines are in the model space already
Daniel Rossberg (Jul 26 2019 at 18:21):dimensionline1.patch
forget the first one see this
As you are already afraid, the current dimension line implementation has no chance to get accepted. But, it contains some useful thoughts. Especially your extensions for the txt_seg struct is something which I would like to see as an own patch.
However, you should work first on your previous patch (consideration of the location of the txt_seg reference point) and polish it such that it can be committed to our repository.
And, I found another bug in the annotation primitive: Sometimes the l command doesn't show the text ("Label text"). It seems to not being really consistent, but mostly the short texts are shown but not the long ones.
If you manage to fix the issues, including the txt_seg struct extensions, it would be a good base for a successful conclusion of your project.
Louis Googl (Jul 26 2019 at 18:32):thank you for the feedback I will work on it, but could you tell me why this approach is not correct for the dimension line?
Daniel Rossberg (Jul 26 2019 at 18:37):for making a dimension line for a 3d object what do you think about changing the verts in rt_annot_internal to 3d point which will work because the lines are in the model space already
I thought about adding a distinct member for 3D points to rt_annot_internal, e.g. like point3d_t *verts3d; and using these if a vertex with a negative index is requested (i.e. transforming this point to the 2D "paper" space and using this in the vlist then). But, I don't think that this will be enough to create nice dimension lines. Or?
Louis Googl (Jul 29 2019 at 17:42):pasted image
this is the result of position adjustment
Louis Googl (Jul 29 2019 at 17:51):annotpos.c.patch and this is the patch.
Louis Googl (Jul 29 2019 at 18:00):I will work now on extending the text segment. but can you look at the position patch before if we can commit it first because there will be changes in calling the function bn_vlist_2string() when we add the size and rotation angle
Daniel Rossberg (Jul 29 2019 at 18:48):In general it looks good, but the compilation fails: ant_pos_adjs() is used before it's declared.
Louis Googl (Jul 30 2019 at 15:50):annotpos2.c.patch sorry this is because I used visual studio and it doesn't consider this as an error, this is fixed
Louis Googl (Jul 30 2019 at 23:12):txt1.patch @Daniel Rossberg this for the text segment
Louis Googl (Jul 30 2019 at 23:17):pasted image I couldn't reproduce the L command bug even with the long label.
Louis Googl (Jul 31 2019 at 11:27):but it is obvious that it needs changes to count for the new text segment parameters
Louis Googl (Jul 31 2019 at 15:37):I thought about adding a distinct member for 3D points to rt_annot_internal, e.g. like
point3d_t *verts3d;and using these if a vertex with a negative index is requested (i.e. transforming this point to the 2D "paper" space and using this in the vlist then). But, I don't think that this will be enough to create nice dimension lines. Or?
I think this can be done but can you explain more what do you mean by negative index?
Daniel Rossberg (Jul 31 2019 at 17:55):The points are referenced with integer numbers in the segments. For example, the line has two integers pointing to its start and end point. Well, an integer could be negative ...
Daniel Rossberg (Jul 31 2019 at 17:59):BTW, I'm a bit handicapped these days. I hope I can go back to normality tomorrow.
Louis Googl (Aug 01 2019 at 00:40):BTW, I'm a bit handicapped these days. I hope I can go back to normality tomorrow.
I hope you feel better. :heart:
Daniel Rossberg (Aug 01 2019 at 18:11):BTW, I'm a bit handicapped these days. I hope I can go back to normality tomorrow.
I hope you feel better. :heart:
It was not his kind of handicap. The electric power company removed the connecting cables from my house before the new connection was established. Nobody told me about it in advance. I was completely caught by surprise. Now, after two days without electricity, the new connection is there.
Daniel Rossberg (Aug 01 2019 at 18:40):annotpos2.c.patch sorry this is because I used visual studio and it doesn't consider this as an error, this is fixed
Okay, next gcc build error:
/home/rossberg/Devel/BRL-CAD/GSoC/src/librt/primitives/annot/annot.c: In function ‘ant_pos_adjs’:
/home/rossberg/Devel/BRL-CAD/GSoC/src/librt/primitives/annot/annot.c:175:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
fastf_t lenght = 0;
^~~~~~~
/home/rossberg/Devel/BRL-CAD/GSoC/src/librt/primitives/annot/annot.c:173:14: error: unused variable ‘temp’ [-Werror=unused-variable]
hpoint_t temp = HINIT_ZERO;
^~~~
cc1: all warnings being treated as errors
make[2]: *** [src/librt/CMakeFiles/librt-obj.dir/build.make:700: src/librt/CMakeFiles/librt-obj.dir/primitives/annot/annot.c.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:15482: src/librt/CMakeFiles/librt-obj.dir/all] Fehler 2
make: *** [Makefile:163: all] Fehler 2
Daniel Rossberg (Aug 01 2019 at 19:33):txt1.patch Daniel Rossberg this for the text segment
At the first sight, it looks good. But, it can't handle files with the old format (without the size and angle attribute for the text segments). Is it possible to make it compatible?
Daniel Rossberg (Aug 01 2019 at 19:52):pasted image I couldn't reproduce the L command bug even with the long label.
This is a file where I observed the odd behavior: l_annot.g
an0.a is okay, an1.a is not.
Louis Googl (Aug 02 2019 at 16:50):I compiled it on gcc antpos.diff
Louis Googl (Aug 02 2019 at 17:18):txt1.patch Daniel Rossberg this for the text segment
At the first sight, it looks good. But, it can't handle files with the old format (without the size and angle attribute for the text segments). Is it possible to make it compatible?
pasted image
this is what happens when you call the get command on the old version of the annotation I am working on it
Daniel Rossberg (Aug 03 2019 at 15:38):I compiled it on gcc antpos.diff
Hmm, this looks a bit odd: annot_pos.g
Daniel Rossberg (Aug 03 2019 at 15:41):Nevertheless, you should work on the patches on sourceforge. The test function is still open there, and for the annotation position you should open a patch ticket there too.
Louis Googl (Aug 03 2019 at 17:59):(deleted)
Louis Googl (Aug 03 2019 at 19:02):Nevertheless, you should work on the patches on sourceforge. The test function is still open there, and for the annotation position you should open a patch ticket there too.
sorry I usually get an email from SourceForge when you replay this time I didn't
Louis Googl (Aug 03 2019 at 19:03):@Daniel Rossberg pasted image
It will not work without the rt_g what is wrong with using it ?
Louis Googl (Aug 03 2019 at 19:30):I compiled it on gcc antpos.diff
Hmm, this looks a bit odd: annot_pos.g
pasted image this what is wrong with bottom left that you made you wrot bottom left but as you can see by get command it is top left I am working on the top right
Louis Googl (Aug 03 2019 at 20:14):I fixed the second one also and created a ticket on SourceForge.
Louis Googl (Aug 03 2019 at 21:14):txt1.patch Daniel Rossberg this for the text segment
At the first sight, it looks good. But, it can't handle files with the old format (without the size and angle attribute for the text segments). Is it possible to make it compatible?
the problem of compatibility is in importing function but when I fixed it ruined the new ones I think it doesn't worth it to make it compatible with the previous txt_seg what do you think?
Daniel Rossberg (Aug 04 2019 at 14:18):Daniel Rossberg pasted image
It will not work without the rt_g what is wrong with using it ?
It's wrong, because librt is build on top of libbn, and a library should work without the necessity to use something above it where it shouldn't even know about.
And, you do not need rt_g but rt_g.rtg_vlfree, which is a struct bu_list.
int
vlist_main(int argc, char* argv[])
{
point_t ptzero = VINIT_ZERO;
struct bu_list head;
struct bu_list vlfree;
int cmd_cnt_length = 0;
int expected_length = 0;
sscanf(argv[1], "%d", &expected_length);
if (argc < 2) {
bu_exit(1, "ERROR: input format is test_args [%s]\n", argv[0]);
}
BU_LIST_INIT(&head);
BU_LIST_INIT(&vlfree);
if (expected_length < 0) {
return bn_vlist_cmd_cnt(NULL);
}
for (int i = 0; i < expected_length; i++) {
BN_ADD_VLIST(&vlfree, &head, ptzero, BN_VLIST_LINE_DRAW);
}
cmd_cnt_length = bn_vlist_cmd_cnt((struct bn_vlist*) & head);
return !(expected_length == cmd_cnt_length);
}
And now tell me again why it will not work without the rt_g :rolling_eyes:
Daniel Rossberg (Aug 04 2019 at 16:18):I compiled it on gcc antpos.diff
Hmm, this looks a bit odd: annot_pos.g
pasted image this what is wrong with bottom left that you made you wrot bottom left but as you can see by get command it is top left I am working on the top right
Well, yes, but this is odd: bl.png
Louis Googl (Aug 04 2019 at 19:17):And now tell me again why it will not work without the rt_g :rolling_eyes:
some times I don't see further than my nose :hurt:
I fixed it and put it on SourceForge
Louis Googl (Aug 04 2019 at 19:37):Well, yes, but this is odd: [bl.png](/user_uploads/1549/A4iaLld9PbGZDDh1GIDOUiS6/bl.pngquote
pasted image
I thought that this was the problem but It didn't happen to me
Louis Googl (Aug 04 2019 at 19:43):annotpos4.c.patch try this one
Louis Googl (Aug 04 2019 at 19:44):rt_pos_flag() works fine
Louis Googl (Aug 06 2019 at 18:36):@Daniel Rossberg I found a way to make it compatible with old annotations it can be drawn and the get command works on them but it prints an illogical value of the text size
Louis Googl (Aug 10 2019 at 19:59):@Daniel Rossberg this solves the l command bug can you check it so I can write another one for extending the text segment annot.c.patch
Louis Googl (Aug 10 2019 at 20:00):sorry for being slow but I didn't know how to deal with the database
Daniel Rossberg (Aug 10 2019 at 20:03):Nice that you could solve it. I'll have a look at it on Monday.
Louis Googl (Aug 10 2019 at 20:06):it works but I don't know if this is the perfect way to do it :big_smile:
Louis Googl (Aug 10 2019 at 20:07):annotpos4.c.patch try this one
can you also see this patch please. because the error that you pointed is not happening with me
Louis Googl (Aug 10 2019 at 20:12):it works but I don't know if this is the perfect way to do it :big_smile:
Daniel Rossberg (Aug 10 2019 at 20:16):Sure, I'll go through all your remaining patches ;)
Louis Googl (Aug 10 2019 at 20:41):I have tried the same approach after extending the text segment it works on old annotation which doesn't contain text size and rotation angle but it needs also some changes in seg_to_vlist function and it works on the new and old annotations
Daniel Rossberg (Aug 12 2019 at 19:21):rt_pos_flag() looks wrong. As far as I can see, it slips always in case 3 "top".
Daniel Rossberg (Aug 13 2019 at 18:22):Just saw that you fixed this with your position adjustment patch.
Louis Googl (Aug 13 2019 at 19:13):for the position adjustment, we can't use bn_vlist_bbox() to get the text dimensions because it considers the annotation as a point.
Louis Googl (Aug 13 2019 at 19:13):I am working on the export and import functions I will send a patch for the both problems today
Louis Googl (Aug 13 2019 at 19:25):do you think it is better to use sizeof(char) or just conder char will be 1 byte always?
Daniel Rossberg (Aug 13 2019 at 20:26):I think, you can assume that it's 1 byte.
Daniel Rossberg (Aug 13 2019 at 20:29):BTW, if you stay with your label size computation then you have an indentation issue there (the interior of the for loop).
Louis Googl (Aug 13 2019 at 20:51):bn_vlist_2string() is called twice because it is necessary to do that because the text coordinates should be calculated based on the new reference point.
Daniel Rossberg (Aug 14 2019 at 18:19):bn_vlist_2string() is called twice because it is necessary to do that because the text coordinates should be calculated based on the new reference point.
Okay, I see.
Louis Googl (Aug 16 2019 at 15:02):pasted image
pasted image
I think we need the text segment internals in the exporting function what do you say?
Daniel Rossberg (Aug 16 2019 at 17:03):Sure. Why do you ask? Is it because of my sizeof(struct bu_vls) comment?
Louis Googl (Aug 16 2019 at 17:11):Sure. Why do you ask? Is it because of my sizeof(struct bu_vls) comment?
yes you told me that we don't need the text segment internals
Louis Googl (Aug 16 2019 at 17:27):I added 3d points to the annotation internal it works can you have a look at it, so we will try to use it in dimension line 3dverts.patch
Daniel Rossberg (Aug 16 2019 at 19:48):Sure. Why do you ask? Is it because of my sizeof(struct bu_vls) comment?
yes you told me that we don't need the text segment internals
No, I told you we don't need the bu_vls internals ;)
This is something different.
Louis Googl (Aug 16 2019 at 20:53):Okay now I understand i deleted them in import5 and export5 i will do it in export4 and import4
Louis Googl (Aug 17 2019 at 17:05):@Daniel Rossberg I modified the patches on SourceForge.
Louis Googl (Aug 23 2019 at 21:24):pasted image
@Sean I was reviewing the committed code and found this bug I submitted a solution ticket number 534
Sean (Aug 23 2019 at 22:02):Great @Louis Googl ! I'll try to take a look at it soon. What command resulted in the error?
Louis Googl (Aug 23 2019 at 22:02):any annotation drawing
Louis Googl (Aug 23 2019 at 22:04):because it is in ant_label_dimensions() function.
Louis Googl (Aug 25 2019 at 14:14):pasted image
@Daniel Rossberg what do you think ?
Daniel Rossberg (Aug 25 2019 at 17:30):Well, the question isn't: box yes or no. It's for sure a very desirable feature. But, you implemented it as a kind of hardcoded hack. You can't invent for every feature a new type or flag. Is there really no way to say it with the existing lines and text logic? I think, we need a bit more flexibility there.
Louis Googl (Aug 25 2019 at 17:33):so you think it is better if all the labels have a box? we will not make it a choice for the user?
Louis Googl (Aug 25 2019 at 17:34):labelbox.patch this is the patch
Louis Googl (Aug 25 2019 at 17:34):I am working on the report I will send the link in 3 to 5 hours
Louis Googl (Aug 25 2019 at 17:36):so you think it is better if all the labels have a box? we will not make it a choice for the user?
it is possible to implement it without the flag. but do we want to prompt the user for it or not ?
Daniel Rossberg (Aug 25 2019 at 17:40):so you think it is better if all the labels have a box? we will not make it a choice for the user?
No. I think it would be better to draw the box with line segments instead of having e new flag for it.
Daniel Rossberg (Aug 25 2019 at 17:40):labelbox.patch this is the patch
That's why I knew about the flag ;)
Daniel Rossberg (Aug 25 2019 at 17:43):so you think it is better if all the labels have a box? we will not make it a choice for the user?
it is possible to implement it without the flag. but do we want to prompt the user for it or not ?
I think, with the existing annotation features it's not possible. We would need more flexibility there.
And, the in command is a different question: Which annotation types shall be supported by in commands?
Louis Googl (Aug 25 2019 at 17:49):No. I think it would be better to draw the box with line segments instead of having e new flag for it.
this is possible but still the issue of user choice.
Louis Googl (Aug 25 2019 at 17:53):I think, with the existing annotation features it's not possible. We would need more flexibility there.
can you explain more? like what do we need to add and why?
Louis Googl (Aug 25 2019 at 17:54):And, the in command is a different question: Which annotation types shall be supported by in commands?
I think the dimension line and the current annotation more complex annotations will need an editor I think. or it has to have a static templet
Daniel Rossberg (Aug 25 2019 at 18:33):I think, with the existing annotation features it's not possible. We would need more flexibility there.
can you explain more? like what do we need to add and why?
For this kind of boxes the lines had to know the size of the text segment.
Daniel Rossberg (Aug 25 2019 at 18:36):However, there are other kinds of boxes, e.g. legends, where the size of the box is fixed.
Louis Googl (Aug 25 2019 at 20:55):https://brlcad.org/wiki/User:Ali_Haydar/GSOC19/Report @Daniel Rossberg @Sean @Shubham Rathore this is my report can I have some feedback, please.
Sean (Aug 26 2019 at 17:18):@Louis Googl I take from the diagram that I maybe didn't update all the right variables when I flipped the coordinates from 3rd quadrant to 1st?
Sean (Aug 26 2019 at 17:19):if so, I will certainly go back and fix it
Sean (Aug 26 2019 at 17:19):overall it looks good though it would like to see an example of labels with geometry as sort of a final demonstration
Sean (Aug 26 2019 at 17:21):like a top-down rendering of one some sample model (one existing or a simple one you create) showing a title annotation in one corner, a couple labels identifying different objects, and height/width dimension labels. if you create this demo, we can include it in the db/ directory as an example for others.
Louis Googl (Aug 26 2019 at 20:14):like a top-down rendering of one some sample model (one existing or a simple one you create) showing a title annotation in one corner, a couple labels identifying different objects, and height/width dimension labels. if you create this demo, we can include it in the db/ directory as an example for others.
I think I can do that but the dimension line is not accepted yet
Daniel Rossberg (Aug 27 2019 at 07:10):like a top-down rendering of one some sample model (one existing or a simple one you create) showing a title annotation in one corner, a couple labels identifying different objects, and height/width dimension labels. if you create this demo, we can include it in the db/ directory as an example for others.
I think I can do that but the dimension line is not accepted yet
You could do this with your development version. It's for documenting your work.
How much of your work will be used in the program is another question - which will be asked the mentors in their evaluation, for example.
Louis Googl (Aug 28 2019 at 11:59):like a top-down rendering of one some sample model (one existing or a simple one you create) showing a title annotation in one corner, a couple labels identifying different objects, and height/width dimension labels. if you create this demo, we can include it in the db/ directory as an example for others.
I think I can do that but the dimension line is not accepted yet
You could do this with your development version. It's for documenting your work.
How much of your work will be used in the program is another question - which will be asked the mentors in their evaluation, for example.
@Daniel Rossberg okay, I am working on it but I thought If we will put it in db/directory it has to be accepted before. also, I am working on the text segment patch
Daniel Rossberg (Aug 28 2019 at 17:24):That's right, the demo in db/directory can only include accepted features. But, you could create demos for your pending patches too, and attach them to the corresponding patch tasks.
Louis Googl (Aug 28 2019 at 20:30):how about the 3d verts? have you seen the patch?
Louis Googl (Aug 28 2019 at 20:32):and you think it is better to write a new function seg_to_vlist or use negative indexing?
Louis Googl (Aug 28 2019 at 21:13):pasted image the text of the dimension line is calculated based on the coordinates of the points
Louis Googl (Aug 28 2019 at 21:16):if we want to apply the position flags on it, this will need a new function to work on V, not on tsg->ref_pt.
Daniel Rossberg (Aug 29 2019 at 19:26):I had only a brief glance at your other patches, because I have to think about their consequences for future developments first. But, I can ensure you that I will take a close look at each of them.
Louis Googl (Sep 01 2019 at 12:17):I think the text segment patch didn't work for you because I used my patch form the old version on the new version and continue the adjustments :slight_smile: , I have an exam tomorrow and other three on the 9th, 10th, 12th of September :joy:
Louis Googl (Sep 02 2019 at 11:12):@Sean pasted image
Sean (Sep 05 2019 at 15:24):@Louis Googl This looks pretty good but how about a bit more showmanship, more annotations... Can you put a "Annotations Demo" label in the top-left corner? On second thought, an ellipsoid would be much more interesting, even the default "make ell ell" will give a nice 2:1 ratio. If you change the text of shper to something more meaningful like "center" or "center point" and ideally not overlapping the edge of the circle, so try putting the point fully in or fully outside. The dimension line looks great, but try placing it below instead of above and adding another on the right or left side (whichever looks best to you). Last but not least, you could put a label in a box showing the multiline you had working or was that too experimental?
Louis Googl (Sep 05 2019 at 15:29):@Sean thank you for your nots I think I can do it all. for the multiline annotation, I haven't work on it yet.
Louis Googl (Sep 05 2019 at 15:32):for the location of the dimension line the default I made for the verts is to be 10 mm above the first and second points. and I am thinking to allow the user to specify this feature (how far the dimension line from the points)line between
Sean (Sep 05 2019 at 16:09):
Sean (Sep 05 2019 at 16:10):Here's kind of what I had in mind.
Sean (Sep 05 2019 at 16:11):note you can get thicker wireframe lines in mged with "rset var linewidth 3"
Sean (Sep 05 2019 at 16:12):makes for a better screenshot
Louis Googl (Sep 07 2019 at 15:30):very nice It can be done, I will do it next week because I have three exams this week. thank you for your notes
Sean (Sep 11 2019 at 21:22):@Louis Googl good luck with your exams. if there's additional annotations you can think of adding to the example, please do. We don't want annotations overlapping, but even "tricks" like underlining or drawing a box around something of interest or denoting values (e.g., "ae 0 90") can make for a helpful demonstration.
Louis Googl (Nov 05 2019 at 13:30):@Daniel Rossberg hell Mr. daniel I have fixed the patch for extending the text segment could you please give me feedback about the other patches and your general view for development. like 3d verts and the dimension line .
Daniel Rossberg (Nov 05 2019 at 19:23):Thanks, I'll have a look at it. But, it may take a while...
Louis Googl (Nov 07 2019 at 14:51):@Daniel Rossberg hell Mr. daniel I have fixed the patch for extending the text segment could you please give me feedback about the other patches and your general view for development. like 3d verts and the dimension line .
Louis Googl (Mar 01 2020 at 17:41):@Daniel Rossberg Hello Mr. Daniel I was working on the problem you told me about ( converting the annotation asc2g) I made this solution it is not final but this is my first try I would appreciate your feedback annot.c.patch
Louis Googl (Mar 01 2020 at 17:43):also after adding the new text segment parameters (size, rotation angle), it needs more adjustments. which one you think is better to work on first?
Sean (Mar 02 2020 at 03:57):@Louis Googl awesome! glad to see you working on this again.
Sean (Mar 02 2020 at 03:58):however, question though. Is this supposed to be an extension of the code on trunk? the ant_return_rel_pos() function is worrisome because of all the embedded strings. that taxonomy doesn't appear to be defined or documented anywhere.
Sean (Mar 02 2020 at 04:01):typically for g2asc conversions and their counterpart asc2g conversions, keyword labels are used, but those verbose versions are going to be incredibly "expansive" (i.e., awkward if there are lots of annotations as the .asc might become huge)
Sean (Mar 02 2020 at 04:02):shorter labels might help with that some (e.g., using the same as the enumeration like BL, BC, ML, etc)
Louis Googl (Mar 02 2020 at 11:11):@Sean Hello, Mr. Sean hope you are in well condition. I would like to do more if possible, I would like if you can give me feedback about my open patches of the dimension line and the box around annotation. I have passed my exams and I have some free time I would like to continue my contribution.
Louis Googl (Mar 02 2020 at 11:13):Sean said:
shorter labels might help with that some (e.g., using the same as the enumeration like BL, BC, ML, etc)
it is possible to do like this but the result of get function on the annotation will be different and not as obvious as it is now, I will make a patch and send it to you today
Louis Googl (Mar 02 2020 at 11:15):Sean said:
however, question though. Is this supposed to be an extension of the code on trunk? the ant_return_rel_pos() function is worrisome because of all the embedded strings. that taxonomy doesn't appear to be defined or documented anywhere.
ant_return_rel_pos() I made it for using in ant_get_tcl() because the previous approach was wrong as you can notice.
Sean (Mar 02 2020 at 14:52):I'm not Mr. Sean unless you're in grade school ... ;)
Sean (Mar 02 2020 at 15:07):it is possible to do like this but the result of get function on the annotation will be different and not as obvious as it is now, I will make a patch and send it to you today
the asc form intent is for serialization so the keywords will have to be documented regardless. We just need to make sure they're consistent, documented somewhere, and won't cause a problem. I think the latter is the issue as the long labels are considerably more metadata than the data itself, so the serialized form potentially explodes (e.g., 1MB of annotations turns into 1GB asc file).
Sean (Mar 02 2020 at 15:08):@Louis Googl yes, thank you for the reminder to take a look at your open patches (squeaky wheels get attention these days)
Louis Googl (Mar 02 2020 at 15:30):I will try to do it today thank you for the feed back
Louis Googl (Mar 02 2020 at 23:26):@Sean this is the new patch with the adjustments I have tested it, it works for g2asc and asc2g for annotations annot.c.patch
Daniel Rossberg (Feb 17 2022 at 17:45):Here for discussions about annotations...
Daniel Rossberg (Feb 17 2022 at 17:50):@Himanshu Sekhar Nayak, okay, but this involves many different features.
Daniel Rossberg (Feb 17 2022 at 17:51):You should describe the basic ones first.
Himanshu (Feb 17 2022 at 17:55):Daniel Rossberg said:
You should describe the basic ones first.
Currently what I noticed is that mged can have a mouse pointing feature so that it will be easy to add text labels without giving coordinates. But I don't know how I can proceed with this feature.
Also, another basic one I think is shifting the current in command to have a GUI option like a section Annotate which will contain labels, dimensions, etc.
Himanshu (Feb 17 2022 at 17:56):Both the command line and sketch editor can have section of Annotate.
Daniel Rossberg (Feb 17 2022 at 17:58):I'm afraid you are mixing up something. What do you mean by "in command to have a GUI option"? Do you have an example for this?
Himanshu (Feb 17 2022 at 18:01):Like this to have a separate section in this area. Screenshot_2022-02-17_23-30-31.png
Daniel Rossberg (Feb 17 2022 at 18:02):If there is no section for any other primitive there, it's probable a bad idea to have one for annotations at this place.
Himanshu (Feb 17 2022 at 18:04):So we may shift annotate to sketch editor?
Daniel Rossberg (Feb 17 2022 at 18:05):I wouldn't "shift" it. Where do you find/how do you call the sketch editor?
Himanshu (Feb 17 2022 at 18:09):We can have an Annotate section just like File, Edit, ..... where it will contain labels, dimensions... So after drawing a primitive, a user can go into the annotate section and click on labels to add text to corresponding coordinates.
Daniel Rossberg (Feb 17 2022 at 18:11):Well, Annotate would be more like "Arbs", "Cones & Cylinders", and "Ellipsoides".
Himanshu (Feb 17 2022 at 18:16):Daniel Rossberg said:
Well, Annotate would be more like "Arbs", "Cones & Cylinders", and "Ellipsoides".
Sorry, I don't understand. Is it having annotation for Arbs, Cones & Cylinders?
Daniel Rossberg (Feb 17 2022 at 18:17):If you want to add (create) something, there is the Create menu, where you can find these submenus.
Daniel Rossberg (Feb 17 2022 at 18:18):I.e., if I want to create a new annotation, I would expect the corresponding menu entry there.
Himanshu (Feb 17 2022 at 18:21):Okay, I understand. So adding an annotate section inside create menu?
Himanshu (Feb 17 2022 at 18:22):From there on we can add labels, dimesions, etc inside annotate which will be a part of create menu
Daniel Rossberg (Feb 17 2022 at 18:24):Yes, this would be logical. Unfortunately, all the entries in the Create menu create the primitives without further questions :(
Daniel Rossberg (Feb 17 2022 at 18:27):There was one a sketch editor, probably in the skt_ed.tcl (in tclscripts/mged) script.
Himanshu (Feb 17 2022 at 18:29):Daniel Rossberg said:
Yes, this would be logical. Unfortunately, all the entries in the
Createmenu create the primitives without further questions :frown:
Hmm Create menu is to draw primitives and adding annotate will mixup things.
Daniel Rossberg (Feb 17 2022 at 18:32):The Create menu creates primitives, but always with standard values.
Himanshu (Feb 17 2022 at 18:43):Sorry, due to internet issues I am disconnected in the middle of the discussion.
Himanshu (Feb 17 2022 at 18:46):Daniel Rossberg said:
The
Createmenu creates primitives, but always with standard values.
standard values?
Last updated: Nov 15 2024 at 00:49 UTC