This task involves adding probably less than 10 lines of code.
BRL-CAD has a raytracer / renderer command-line application called "rt" that generates pretty pictures. It has a whole slew of command-line options, and this task entails adding support for one more that sets an object's color.
This task is meant to be proof-of-concept, so here's a crash-course:
- Run "mged -c test.g"
- Say 'y' for yes when it asks whether to create a new database
- Select "nu" on the attach prompt so we stay in command-line mode
- Run "make sph sph" to create a sphere
- Run "r sph.r u sph" to make a solid region out of the sphere
- Run "mater sph.r plastic 255 0 0 ." to make the sphere red
- Run "quit" to exit mged
- Run "rt -s1024 -C255/255/255 test.g sph.r" to render the sphere in a 1024x1024 window with a white background specified.
Now your task is to make it so that we can override that sphere's red color (just temporarily) during rt. Make something like this work:
rt -s1024 -C255/255/255 -O0/0/255 test.g sph.r
That will set the 0/0/255 color on the specified sph.r object and it should render blue. That is it!
Code:
- src/rt/opt.c
- src/rt/view.c
- src/rt/do.c
- src/rt/worker.c
- src/rt/main.c
You won't necessarily need to modify all of those (I did claim this was probably 10 lines after all), but the code you add will probably be to one of those five files. A hint to get you started, look for bu_getopt() and find where -C is getting processed. That may help creating a -O (or similar option if -O is already taken).
Submit your work as a single patch file. See http://brlcad.org/wiki/Patches for help.
File name/URL | File size | Date submitted | |
---|---|---|---|
ged.patch | 951 bytes | December 29 2012 16:29 UTC | |
opt2.patch | 2.4 KB | December 30 2012 15:02 UTC | |
rt.patch | 3.9 KB | January 08 2013 03:57 UTC | |
rt2.patch | 5.6 KB | January 09 2013 04:57 UTC | |
rt3.patch | 4.9 KB | January 09 2013 22:44 UTC |
I would like to work on this task.
This task has been assigned to javamonn. You have 72 hours to complete this task, good luck!
So, I have the option added and the color parsed, but I'm unsure as to how to change the color of the rendering. Is there a function I should be calling? Or maybe a way to overwrite the color of the pixels worker.c is producting? I'd appreciate any help you could give me.
Thanks,
Daniel
The claim on this task has been removed, someone else can claim it now.
Where is the function that sets the colour of the object? And where is the color specified in "mater sph.r ..." written to?(I'm assuming it's written to some file since that colour is accessible by rt even after mged is closed.)
To the database, of course. That question was probably stupid.
In function "get_args" in opt.c, where the cmd line options are processed, I see that the operations specified from the command line are executed using the function "rt_do_cmd." To set background color, the string "set background=x/y/z" is passed to rt_do_cmd. Is there any such command/statement that would let me change the color of the current rendered object from rt_do_cmd?
Your questions are basically asking "where's the code that does this for me?" We never said there was. ;)
The task could involve the rt_do_cmd() if you like, but it's enough work to figure out how to set the color (see what some of the ged functions (src/libged/*.c) related to color do in their implementation).
This task only involves adding that option support, but not doing anything with it?
You've got it backwards. The task is to figure out how to set a color (in code, on an object, NOT how to read a value from a user), set a temporary color, and show that it works. The task description uses a -O option as an example because the user will obviously need to specify a color somehow. Reading a color from the user that way is trivially easy if our -C option is used as an example. The work, though, is to FIGURE OUT how to set object colors. Try to render all objects as red (255/0/0) regardless of their default/set color, for example.
I would like to work on this task.
This task has been assigned to Skriptkid. You have 72 hours to complete this task, good luck!
What is the structure "ged" used for? Does it need to be fiiled with certain values before being passed to the GED functions?(Functions such as GED_CHECK_DATABASE_OPEN, GED_DB_PUT_INTERNAL, etc) Also, what does the function RT_CK_COMB do?
It's not complete, but I just wanted to know if I've understood the option part right. Also, there's a change I've made to a break statement, which I'm pretty sure was an error,(unless it was where it was for a purpose.)
The work on this task is ready to be reviewed.
Why does that error arise? Do I have to the add the option somewhere else also?
You need to add your option to the bu_getopt option string. See the getopt man page.
One of the mentors has sent this task back for more work. Talk to the mentor(s) assigned to this task to satisfy the requirements needed to complete this task, submit your work again and mark the task as complete once you re-submit your work.
The GED structure represents a geometry database editing context. If you run "ged_draw()" for example, the GED structure contains the information about which .g file to read from.
The RT_CK_COMB() is to ensure that the a given combination structure is valid memory-wise. There are macros like that for nearly all structures to validate their memory and detect corruption quickly.
#define GETOPT_STR\
".:,:@:a:b:c:d:e:f:g:h:ij:k:l:n:o:p:q:rs:tu:v:w:x:A:BC:D:E:F:G:H:IJ:K:MN:O:P:Q:RST:U:V:WX:!:+:"
to
#define GETOPT_STR\
".:,:@:a:b:c:d:e:f:g:h:ij:k:l:n:o:p:q:rs:tu:v:w:x:z:A:BC:D:E:F:G:H:IJ:K:MN:O:P:Q:RST:U:V:WX:!:+:"
But the option '-z' or '-zoptarg' still don't work.
It's a little concerning that you can't figure out how to properly add a new command-line option given there are dozens of other options to follow by example... That's because setting the color will require a fair bit more understanding of code.
As for the getopt failure, you found the option string and seem to have added z: correctly. You also have to find where bu_getopt is called and make sure you handle the option there.
That sais, again this is entirely secondary to the task -- you could frankly gang off of the -C color parsing first and see if you can change an object color instead of the background color.
I understand the code, but it's just that I'm not able to completely understand where things are being processed and what certain BRL-CAD functions are doing.
bu_getopt is called only in get_args, which is called in main.c. So the processing of flags is happening in opt.c
I took a look at mater.c, which processes the mater command and saw how it sets the colour of the object. I could get a fair idea about the logic and what the functions are doing and I added a new function to opt.c, which is called by the -C flag. Problem is, this is still changing the background color. What's wrong, and more importantly what have I got right?
It's in opt2.patch
That's looking like progress! It looks like you're on the right track without a few exceptions. You did hook into the -C option and change the behavior there, so that's good for testing. If the background is still changing, though, you may not be recompiling/testing correctly since you clearly removed the code that called rt_do_cmd() which is what set the background global to the -C color. Put a bu_log() or printf() statement before change_color() (should use consistent spelling) and make sure you're running the right binary when you're testing.
As for the change_color() command, that's a good first step looking at what the matter command does. Note, however, that it's not an acceptable final solution as that method involves updating the comb structure and then WRITING IT OUT TO DISK (via GED_DB_PUT_INTERNAL())... you'll need to find a method that doesn't require read/write access to the .g file and doesn't write to disk. Try to get it to work that way first, though, to make sure you're passing parameters correctly. I don't see you verify that argc/argv are actually geometry names and not other parameters, for example. Print argv to make sure it's actually geometry and not a file name or option while testing.
Need an extension. Sorry. Haven't been able to work on this for sometime.
Melange has detected that the final deadline has passed and it has reopened the task.
I would like to work on this task.
This task has been assigned to Skriptkid. You have 72 hours to complete this task, good luck!
The claim on this task has been removed, someone else can claim it now.
I would like to work on this task.
This task has been assigned to javamonn. You have 72 hours to complete this task, good luck!
The work on this task is ready to be reviewed.
I'm pretty sure this is the correct way to go about things, that is, changing the color in the application struct. I'm unsure as to where to do it however, right now I have it in main but I'm unsure if it gets overwritten again since I have it to early. Could I move this assignment into the view_pixel() function, since that seems to be where the values for color are actually read, or do I have to change the application struct as a whole? It looks like compiling is broken right now, otherwise I'd be trying these things out.
Another approach I could see is changing the values for color for the regions as theyre being read in the view_setup() function, but this technically requires read access of the .g files.
Thanks for the help,
Daniel
Have you tested your patch to see how it actually works?
Try rendering the moss.g example (the all.g object) and set the color to green (0/255/0). What does the result look like? It should look as if you'd set the all.g's color to green within mged.
One of the mentors has sent this task back for more work. Talk to the mentor(s) assigned to this task to satisfy the requirements needed to complete this task, submit your work again and mark the task as complete once you re-submit your work.
I feel like I'm close, but I'm not quite there yet. Changing the application color did not work in the end, so my strategy now was to change the color the regions in the rt instance struct after they are read in with rt_dirbuild() in main.c. I figured this would be a fool proof way to get the temp color to render, since your changing the value within the rt_i struct. It doesn't work like I had expected though. The object still renders in the original color, even though those values have been overwritten in the region. Unless I'm missing something obvious somewhere, like how rt_dirbuild reads in the values. I'm beginning to think that I might have to change values elsewhere within the rt_i struct as well. I mainly wanted to provide a status update, I included the current (non working) patch if you want to take a look at it. Please let me know if I'm waayyyy off. I feel like I'm in the ballpark though. Plenty of troubleshooting to be done ;)
Thanks,
Daniel
You're definitely on the right track. This is from memory so I could be wrong, but I think you're going to want to modify the ma_color value in a struct region. Jump to src/rt/view.c and look at view_setup(). It's possible to set the color somewhere else in the pipeline, like before struct region objects are initialized, but it should be simpler in view_setup().
The work on this task is ready to be reviewed.
I knew I was close. I was doing exactly that, overwriting the values in ma_color, but I guess it was too early in the process since I had put it in main. It works well now that the overwriting happens in view_setup(). You can use the option with "-m" followed by rgb values formatted in the same way as the -C option. Let me know if anything should be tweaked.
Thanks,
Daniel
Congratulations, this task has been completed successfully.
That's much better. We'll incorporate a substantially modified version of your patch in the near future, but will be crediting you with your contribution in our authorship file and release notes when it goes live.
If you provide your full name, we'll use that (apologies if this is a repeat question -- lots of tasks). If you join our brlcad-news mailing list, you'll see the posting when it happens.
As GCI comes to a close, we wanted to take the time to say THANK YOU for all your efforts. This comment interface closes after GCI is over, so you're encouraged to join our mailing list where we'll be announcing contributions from GCI participants like yourelf over the upcoming months:
https://lists.sourceforge.net/lists/listinfo/brlcad-news
If you've provided your full name, we'll be sure to credit you in our authorship documentation and you'll see your name in a future announcement. If you contact us at devs@brlcad.org or via IRC, we'll even let you know when your work is integrated and follow up with updates. You're welcome and encouraged to contact us any time, especially if you have a question about how to continue participating in Open Source after GCI is over, but even if just to keep in touch. Note that ongoing participation in Open Source is one of the most impressive skills to have on your resumé. Take care, be well, and thank you again!