Add a command-line option that sets an object color temporarilyBRL-CAD
Status: ClosedTime to complete: 72 hrs Mentors: SeanTags: 3D, raytracing, getopt, option parsing, C

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
Next, render:
  • 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. 

Uploaded Work
File name/URLFile sizeDate submitted
ged.patch951 bytesDecember 29 2012 16:29 UTC
opt2.patch2.4 KBDecember 30 2012 15:02 UTC
rt.patch3.9 KBJanuary 08 2013 03:57 UTC
rt2.patch5.6 KBJanuary 09 2013 04:57 UTC
rt3.patch4.9 KBJanuary 09 2013 22:44 UTC
Comments
javamonnon December 24 2012 18:49 UTCTask Claimed

I would like to work on this task.

Harmanpreet Singh on December 24 2012 19:21 UTCTask Assigned

This task has been assigned to javamonn. You have 72 hours to complete this task, good luck!

javamonnon December 24 2012 20:26 UTCA little confused...

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

javamonnon December 25 2012 04:31 UTCClaim Removed

The claim on this task has been removed, someone else can claim it now.

Skriptkidon December 27 2012 17:37 UTCSetting the color

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.)

Skriptkidon December 27 2012 17:51 UTCDatabase

To the database, of course. That question was probably stupid.

Skriptkidon December 27 2012 18:02 UTCColor

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?

Sean on December 28 2012 08:59 UTCclose questions

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).


 

Skriptkidon December 28 2012 12:39 UTCSo...

This task only involves adding that option support, but not doing anything with it?

Sean on December 29 2012 05:52 UTCNope

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.


 

Skriptkidon December 29 2012 12:04 UTCTask Claimed

I would like to work on this task.

Andrei Popescu on December 29 2012 12:36 UTCTask Assigned

This task has been assigned to Skriptkid. You have 72 hours to complete this task, good luck!

Skriptkidon December 29 2012 16:03 UTCged

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?

Skriptkidon December 29 2012 16:35 UTCCheck

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.)

Skriptkidon December 29 2012 16:35 UTCReady for review

The work on this task is ready to be reviewed.

Skriptkidon December 29 2012 18:05 UTCBad option?

Why does that error arise? Do I have to the add the option somewhere else also?

Sean on December 29 2012 18:51 UTCman getopt

You need to add your option to the bu_getopt option string.  See the getopt man page.

Sean on December 29 2012 18:51 UTCTask Needs More Work

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.

Sean on December 29 2012 22:16 UTCged structure

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.

Skriptkidon December 30 2012 05:29 UTCopt

#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.

Sean on December 30 2012 05:57 UTCgetopt isn't the main goal

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.


 

Skriptkidon December 30 2012 15:02 UTCmater

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?

Skriptkidon December 30 2012 15:03 UTCCode

It's in opt2.patch

Sean on December 30 2012 16:52 UTCprogress!

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. 

Skriptkidon January 1 2013 11:01 UTCExtension

Need an extension. Sorry. Haven't been able to work on this for sometime. 

Melange on January 1 2013 12:36 UTCTask Reopened

Melange has detected that the final deadline has passed and it has reopened the task.

Skriptkidon January 1 2013 14:50 UTCTask Claimed

I would like to work on this task.

Harmanpreet Singh on January 1 2013 15:11 UTCTask Assigned

This task has been assigned to Skriptkid. You have 72 hours to complete this task, good luck!

Skriptkidon January 2 2013 15:51 UTCClaim Removed

The claim on this task has been removed, someone else can claim it now.

javamonnon January 6 2013 22:40 UTCTask Claimed

I would like to work on this task.

Sean on January 7 2013 07:51 UTCTask Assigned

This task has been assigned to javamonn. You have 72 hours to complete this task, good luck!

javamonnon January 8 2013 03:57 UTCReady for review

The work on this task is ready to be reviewed.

javamonnon January 8 2013 04:03 UTCI'm pretty sure...

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 

Sean on January 8 2013 21:40 UTCtested?

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.


 

Sean on January 8 2013 21:40 UTCTask Needs More Work

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.

javamonnon January 9 2013 05:06 UTCI feel like I'm close...

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

Sean on January 9 2013 05:57 UTCdefinitely on the right track

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(). 

javamonnon January 9 2013 22:44 UTCReady for review

The work on this task is ready to be reviewed.

javamonnon January 9 2013 22:51 UTCKnew it...

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

Sean on January 10 2013 05:00 UTCTask Closed

Congratulations, this task has been completed successfully.

Sean on January 10 2013 05:02 UTClooks great

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.


 

Sean on January 14 2013 15:04 UTCthank you

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!


With your numerous completed tasks, your name is going to be all over the place.  With your background and abilitiies, we hope you stay involved. ;)