Jeff Sieu (Dec 11 2017 at 04:28): Jeff Sieu (Dec 11 2017 at 04:28):How can I create a submodel? I have tried in <name> submodel but I'm not sure what is a space partitioning method and treetop that is later requested.
Sean (Dec 11 2017 at 06:40):@Jeff Sieu a "treetop" is just poorly worded -- it refers to an object that you want to reference. space partitioning method shouldn't matter...
Jeff Sieu (Dec 11 2017 at 06:45):I've tried in bishop.g submodel bishop.r / bishop.g while having chessscene.g opened. I have chessscene.g and bishop.g in the same folder. But it gave me Cannot open geometry database file (bishop.g) to store plot
bishop.g: plot failure
_db_walk_subtree() FAIL on '/bishop.g'
Jeff Sieu (Dec 11 2017 at 14:00):so, what is the correct way to use the submodel command?
Jeff Sieu (Dec 11 2017 at 14:25):Ok, turns out that the path that this command takes it in is not relative to the .g file that is currently open. I've only got it to work when I input the absolute path of the .g I want to import the model from.
Mitesh (Dec 11 2017 at 14:28):Are you talking about the task i am working on i.e appleseed#2?
Jeff Sieu (Dec 11 2017 at 14:30):No, I'm talking about the command in <name> submodel in MGED.
Mitesh (Dec 11 2017 at 14:30):okk sorry to interupt
Jeff Sieu (Dec 11 2017 at 14:31):Also trying to do that task, but I get some weird error 0xc0000007b when I run it.
Jeff Sieu (Dec 11 2017 at 15:52):Is there a way to translate submodels? Using Primitive Selection does not seem to work.
Jeff Sieu (Dec 11 2017 at 16:51):Update on the path thing: relative path sort of works but the console is cd-ed into the BRL-CAD installation folder instead of the folder containing the opened database, so anything relative has to be placed inside the installation folder, which is quite weird
Sean (Dec 11 2017 at 17:06):yes, it's simply relative to the current working directory, which isn't right
Sean (Dec 11 2017 at 17:06):that directory can be changed by a user (try just typing "cd /some/new/path" for example)
Sean (Dec 11 2017 at 17:07):pwd will tell you where you're at
Sean (Dec 11 2017 at 17:07):that's why the task added is to implement a function that will do the right thing
Sean (Dec 11 2017 at 17:08):given the current database path (which will be a full or relative path), you'll use bu_basename and/or bu_dirname or other path/subpath functions and figure out what to do with the submodel path (which will also be a full or relative path).
Sean (Dec 11 2017 at 17:10):probably something like these four cases: dbfull+smfull => smfull ; dbfull+smrelative => dbfull/smrelative ; dbrelative+smfull=>smfull ; dbrelative+smrelative => dbrelative/smrelative
Sean (Dec 11 2017 at 17:11):(i guess that's technically just two cases)
Jeff Sieu (Dec 23 2017 at 11:11):Hi, how do I get the directory of the currently opened database in submodel.c, I thought it was struct db_i *sub_dbip; but this seems to be a pointer to the database that the submodel references, not the database of the instanced submodel.
Jeff Sieu (Dec 23 2017 at 12:00):Is there a way to translate submodels? Using Primitive Selection does not seem to work.
And also, how may I translate submodels?
Sean (Dec 24 2017 at 18:53):Is there a way to translate submodels? Using Primitive Selection does not seem to work.
And also, how may I translate submodels?
Honestly, we're not even sure if it works or not -- but the raw way about be to "sed" the submodel and run "tra" command or put the submodel into a combination and "oed" the comb (there's an entire guide on the oed command on the website) to tra the submodel.
Jeff Sieu (Dec 25 2017 at 00:59):Yeah, I had resorted to that, but it seems like it doesn't work. When I sed it then translate it, it simply doesn't move, even when I "accept". When I oed it on its own, it moves correctly when translated, but once I accept it, it snaps back into its original position which is centered at around x=0 and y=0. Or do I have to enclose every submodel in a comb, then oed the submodel via the comb? I've not tried that yet, but since I'll have to translate the submodel individually for the 20 chess pieces, I think it may not be so great to create 20 combinations, then nesting one submodel in each combination, then translating.
What are your opinions?
Sean (Dec 25 2017 at 07:21):I'd see first if embedding in a comb, edited via oed works at all. if it doesn't, then there's no way to set up the scene as submodels. if there is, then that's the way to go for now until some change is made.
Parth Pandya (Dec 25 2017 at 09:11):hi!
Parth Pandya here...!
Participating in GCI.
Siddharth (Dec 25 2017 at 13:41):Welcome @Parth Pandya
Jeff Sieu (Dec 31 2017 at 18:31):Hey, I'm on the submodel absolute/relative path task now, I am able to get the paths to work fine when using the submodel on its own (like when running draw <submodel> then rt.
However, it now fails when I try to use it within a combination:
comb <combination> u <submodel> then draw <combination> does display the wireframe of the submodel like it should, but running rt causes db_walk_subtree to fail. error image
I've attempted to go through the many files involved in this, like tree.c, but couldn't seem to pinpoint the problem. Is there another place where something similar to &sip->file is called, but except it's done generally for all db objects (maybe rt_db_internal?), which may be retrieving the submodel file from the wrong directory still?
Jeff Sieu (Jan 01 2018 at 09:24):Okay, I've since solved the problem.
Jeff Sieu (Jan 01 2018 at 09:27):But now a new problem arises: When I try to raytrace submodels, they seem to be fine, but as I keep adding and adding submodels to be drawn by executing more draws, eventually it stops working and displays the previous version of the raytrace instead of with the new object.
Sean (Jan 02 2018 at 14:30):Hey, I'm on the submodel absolute/relative path task now, I am able to get the paths to work fine when using the submodel on its own (like when running
draw <submodel>thenrt.
However, it now fails when I try to use it within a combination:
@Jeff Sieu belated reply, but I presume from your later message that you figured out the submodel-in-comb issue. if a primitive fails to prep (which means it's *_prep() function returned an error code), then you'll see it listed in the text output like in your log where it said "_rt_gettree_leaf(a1_rook_white): prep failure". Since a1_rook_white failed, there was nothing left to raytrace, so it stopped.
Sean (Jan 02 2018 at 14:34):But now a new problem arises: When I try to raytrace submodels, they seem to be fine, but as I keep adding and adding submodels to be drawn by executing more
draws, eventually it stops working and displays the previous version of the raytrace instead of with the new object.
@Jeff Sieu when you run rt, try rt -F/dev/Xl
Sean (Jan 02 2018 at 14:35):From some other testing, I think there's a bug in the default ogl framebuffer on some platforms that makes it not draw an updated rendering -- /dev/X doesn't draw the same
Sean (Jan 02 2018 at 14:36):another trick can be to add -W every other time to flip the background from black to white
Jeff Sieu (Jan 02 2018 at 14:36):yeah, it was so. i started by searching for the file displaying the prep failure, then slowly discovered the rt_db_internals, functabs and all that, thinking there was some kinda function that does &sip->file but in general for all object -- just for it to lead me straight back to submodel.c. Then I simply did make install and it just updated. what a journey
Jeff Sieu (Jan 02 2018 at 14:40):But now a new problem arises: When I try to raytrace submodels, they seem to be fine, but as I keep adding and adding submodels to be drawn by executing more
draws, eventually it stops working and displays the previous version of the raytrace instead of with the new object.@Jeff Sieu when you run rt, try rt -F/dev/Xl
Okay thanks, i'll try it out. Regarding this, I discovered there were commands like debug<x> (for example debuglib). I tried debuglib 1, then the next thing I knew 10 lines of text appears in the console per second. What is the proper way to use these commands? And how are they turned off? Tried debuglib 0 and didn't work...
Sean (Jan 02 2018 at 14:50):nearly all of the primitives lead back to the base callback functions up in src/librt/primitives/* ... except for the non-leaf and non-geometric entities like comb and binunif, which are currently still in their own directories in src/librt/subdir
Sean (Jan 02 2018 at 14:51):for the debugging flags, there are a set of bit flags that can be set with one set for libbu, another for librt, and yet another for the rt binary itself
Sean (Jan 02 2018 at 14:55):all three sets of flags can be directly set when you run rt using the -x -X and -! command line options. as these are developer options, they aren't documented well but you can see them used throughout the code. so here's a relevant example -- say you're reading src/librt/primitives/submodel/submodel.c and in rt_submodel_prep() you notice a block of debug code starting with:
Sean (Jan 02 2018 at 14:55):if (RT_G_DEBUG & (DEBUG_DB|DEBUG_SOLIDS)) {
Sean (Jan 02 2018 at 14:56):so the flag there is DEBUG_SOLIDS, if we search the headers, we can find its value:
Sean (Jan 02 2018 at 14:56):agua:brlcad.trunk morrison$ grep DEBUG_SOLIDS include//
grep: include/ged/view: Is a directory
include/rt/debug.h:#define DEBUG_SOLIDS 0x00000020 /**< @brief 6 Print prep'ed solids */
Sean (Jan 02 2018 at 14:57):so it's 0x20 and a librt debug flag, so I can run "rt -x20" and it'll run rt with DEBUG_SOLIDS set
Sean (Jan 02 2018 at 14:59):some flags will result in LOTS of output, especially if it's per-ray debugging, so you may want a smaller raytrace (e.g., rt -x20 -s10) or even just reshoot one ray (e.g., rt -x20 -Q 132,317)
Last updated: Jan 10 2025 at 00:48 UTC