| 01:49.25 | *** join/#brlcad louipc (n=louipc@Toronto-ppp221485.sympatico.ca) | |
| 01:49.35 | louipc | how's it going? |
| 01:59.34 | *** join/#brlcad thumPer1052 (n=edward@host-66-205-107-201.classicnet.net) | |
| 02:01.06 | thumPer1052 | good evening gentlemen |
| 02:03.11 | thumPer1052 | When I use 'shaded_mode 2' brl-cad renders invisible objects. |
| 02:03.35 | thumPer1052 | That is objects which have been subtracted. |
| 02:03.55 | thumPer1052 | Is this the state of the software? |
| 02:04.30 | louipc | neat |
| 02:04.51 | thumPer1052 | well... |
| 02:05.00 | louipc | I'm not sure... |
| 02:05.08 | thumPer1052 | neat that it does ANY opengl |
| 02:05.31 | thumPer1052 | is that what yours is doing? |
| 02:06.05 | louipc | shaded_mode 2 is a rendering option? |
| 02:06.15 | thumPer1052 | yes, |
| 02:06.21 | louipc | that never happened to me when rendering |
| 02:06.53 | thumPer1052 | turn on Z clipping Z buffer and lighting |
| 02:07.02 | thumPer1052 | then enter 'shaded_mode 2 |
| 02:07.07 | louipc | I'm just downloading the new version now - I have the first open source version |
| 02:07.09 | thumPer1052 | and redraw something |
| 02:07.14 | thumPer1052 | ahh |
| 02:07.51 | louipc | what is that mode supposed to do? |
| 02:08.34 | thumPer1052 | instead of wireframe, you get solid rendered opengl |
| 02:08.59 | louipc | ah ok |
| 02:09.17 | thumPer1052 | dosen't seem to work very well though |
| 02:09.31 | thumPer1052 | I think they're just starting on the opengl stuff |
| 02:09.54 | louipc | it worked ok for me before - but I have an old version |
| 02:10.42 | thumPer1052 | brl-cad itself works great |
| 02:10.49 | thumPer1052 | this feature is new |
| 02:11.02 | thumPer1052 | or at least hasen't been developed very far |
| 02:12.13 | louipc | ooh you mean they added a solid view of the model for editing? |
| 02:12.24 | thumPer1052 | yeah |
| 02:12.39 | louipc | nice |
| 02:12.50 | louipc | yeah I never used that |
| 02:13.14 | thumPer1052 | it's not very useful yet, but I'm sure they'll sor tit out |
| 02:13.22 | thumPer1052 | er sort it out lol |
| 02:13.56 | louipc | lol |
| 02:15.50 | brlcad | thumPer1052: it's the state of shaded_mode 2, which is very much just an experimental test |
| 02:16.13 | thumPer1052 | ok, thanks. Thats what I suspected. |
| 02:16.13 | brlcad | the wireframe is actually opengl too |
| 02:16.53 | brlcad | archer does it "correctly" as does the new modeler |
| 02:17.14 | thumPer1052 | Thought maybe it was a bug that was being corrected. |
| 02:17.22 | thumPer1052 | archer? |
| 02:17.23 | brlcad | it is a bug :) |
| 02:17.58 | brlcad | and might get corrected .. not clear whether it's worth the effort or to make sure it's okay in the next generation interface |
| 02:18.22 | thumPer1052 | the new modeler is in cvs? |
| 02:18.25 | brlcad | archer is an intermediate visualizer/modeler based on mged |
| 02:18.34 | brlcad | yes, it's in a branch though |
| 02:18.34 | louipc | new ui? |
| 02:18.56 | brlcad | it has a different new ui, yes |
| 02:19.10 | brlcad | both archer and the next generation modeler |
| 02:19.14 | thumPer1052 | I'm learning to like mged |
| 02:19.26 | brlcad | don't worry, your learning isn't going to waste :0 |
| 02:19.28 | louipc | sounds exciting |
| 02:19.29 | brlcad | er :) |
| 02:20.04 | brlcad | everything you do in mged should be accessible in the new interface, it'll just have a better user interface |
| 02:20.14 | thumPer1052 | kewl |
| 02:21.35 | thumPer1052 | what about annotations? |
| 02:21.52 | thumPer1052 | er visible ones |
| 02:26.49 | brlcad | that's already being worked on :) |
| 02:27.34 | brlcad | the ability to store plot files in the .g file too (sort of related) |
| 02:31.45 | thumPer1052 | I was looking at the source, and it is well commented, and pretty clean. |
| 02:31.51 | thumPer1052 | but there's a LOT of it! |
| 02:32.19 | brlcad | patches welcome! |
| 02:33.34 | thumPer1052 | How do you come to terms with a project this big? |
| 02:33.56 | brlcad | focus on some small part of it |
| 02:34.35 | brlcad | it's rather modular and contained, relatively very well organized given it's size |
| 02:35.15 | brlcad | you learn more and more as you go along |
| 02:35.37 | thumPer1052 | I guess start by understanding the database? |
| 02:37.12 | brlcad | depends really |
| 02:37.15 | brlcad | what do you want? |
| 02:37.20 | brlcad | what do you want to do? |
| 02:37.30 | brlcad | what do you want to have/make/create? :) |
| 02:37.35 | thumPer1052 | not sure yet... |
| 02:37.39 | brlcad | :) |
| 02:38.34 | brlcad | step 1 would be to read the very short "volume I" overview of BRL-CAD |
| 02:38.53 | thumPer1052 | k |
| 02:39.12 | brlcad | if you're interested in code, the next step would be to read the HACKING file in the source |
| 02:39.32 | brlcad | from there, it really depends on what you want |
| 02:40.51 | thumPer1052 | As a user, what I'd like to see is the ability to output a 2d vector file. Like we discussed the other day. |
| 02:41.02 | brlcad | "Volume I" is simply: http://brlcad.org/overview.html |
| 02:44.22 | brlcad | the TODO and BUGS files list some good places to start too ;-) |
| 02:44.33 | thumPer1052 | thanks |
| 02:45.00 | brlcad | 2D vector file.. hmm |
| 02:45.42 | thumPer1052 | like a vector option to rtedge |
| 02:45.51 | brlcad | if you know your C, I'd jump right in to rtedge's source code, modify it to output vectors instead of pixels |
| 02:46.47 | brlcad | should be some extra book keeping, a few extra rays to calculate dimensions of requested objects |
| 02:47.22 | thumPer1052 | most of the heavy lifting has probably already been done. |
| 02:47.57 | thumPer1052 | May have to do some line/curve fitting |
| 02:48.56 | brlcad | right, mostly it has (setting up the view projection, firing rays to interrogate geometry, storing hit results, computing rays hitting an edge) |
| 02:50.23 | brlcad | you have a 2D grid and knowledge of exactly what object is at every grid cell -- so computing lines/curves using the edge/pixel values is a direct neighbor search |
| 02:51.30 | brlcad | find all neighbors that are of the sme current cell edge type and you have points in 2D that could be fit to a polynomial/line/curve/whatever |
| 02:52.08 | thumPer1052 | hmmm |
| 02:52.24 | thumPer1052 | might be more straight forward than I thought |
| 02:54.42 | brlcad | getting a vector out of rtedge really shouldn't be hard at all, getting dimensions might be slightly harder since you need to know how/where to orient/display the dimension data onto the vector image |
| 02:56.34 | pra5ad | whoa dejavu |
| 02:56.35 | pra5ad | =) |
| 02:56.51 | brlcad | yeah, and you might get that pra5ad guy to help you out ;) |
| 02:57.07 | pra5ad | u know i woulda coded something up, but lee shot it down |
| 02:57.15 | pra5ad | something about already knowing topology.. |
| 02:58.03 | brlcad | the topology isn't known until you evaluate the boolean |
| 02:58.22 | brlcad | and evaluate the implicits |
| 02:58.35 | brlcad | neither of which is done for free |
| 02:58.46 | thumPer1052 | yes, I see that... |
| 02:59.17 | brlcad | you have to either raytrace, where you evaluate both boolean and implicits at once, or you tesselate, where you evaluate the boolean an an explicit form |
| 02:59.42 | brlcad | he's probably thinking the latter, which I'd say looks like crap for a vector |
| 02:59.57 | pra5ad | *shrug* |
| 03:00.14 | thumPer1052 | innacurate also |
| 03:00.20 | brlcad | plus you have to tesselate.. which .. can be painful |
| 03:00.42 | brlcad | until someone fixes/replaces/improves the tesselation |
| 03:00.51 | pra5ad | whoa dejavu again |
| 03:00.57 | brlcad | werd |
| 03:01.13 | pra5ad | according to mgmt i can't provide external support |
| 03:01.15 | pra5ad | =) |
| 03:01.20 | brlcad | hehe |
| 03:02.25 | brlcad | telling you, just have to work on something useful a few hours a week and deliver a report on it or deliver it to someone "important" .. then you'll be stuck working on it :) |
| 03:02.44 | brlcad | which means you won't be available to work on other stuff as much, of course |
| 03:03.12 | pra5ad | meh |
| 03:03.28 | *** join/#brlcad mahesh (n=mahesh@12-217-228-235.client.mchsi.com) | |
| 03:03.32 | pra5ad | has been since ultimatum |
| 03:03.55 | pra5ad | enjoyed the ftd presentation? |
| 03:04.15 | brlcad | yeah, it was fine |
| 03:04.24 | brlcad | the flower were pretty |
| 03:04.48 | pra5ad | the stems confused me |
| 03:05.16 | brlcad | see, there's something that's seriously needed |
| 03:05.31 | brlcad | something better than boolean and/or trees |
| 03:05.47 | brlcad | or probabilistic trees even |
| 03:05.57 | pra5ad | i was discussing with ``Erik a way to combine both |
| 03:06.02 | brlcad | it's not at all unlike the requirements of a shader language |
| 03:06.13 | pra5ad | oh? |
| 03:06.29 | brlcad | almost identical in many ways |
| 03:06.48 | pra5ad | i dont get the whole flowchart business |
| 03:07.12 | pra5ad | i visualize the 'tree' as a TREE |
| 03:07.13 | brlcad | the next logical progression is to proper flowcharting, which isn't currently used |
| 03:07.31 | pra5ad | the whole system of systems paradigm |
| 03:07.35 | brlcad | it's a simplified flowchart with most of your regular flowchart operators missing |
| 03:07.48 | pra5ad | but it's not supposed to have direction |
| 03:07.55 | pra5ad | where's the flow |
| 03:07.57 | pra5ad | and what is it |
| 03:08.08 | brlcad | but even once/if there was a full flowchart, you run into the issues that programming languages ran into |
| 03:08.47 | brlcad | sure there is flow .. they treat it as states, but the more advanced it gets, you need logic -- iterative logic for starters |
| 03:09.07 | brlcad | if X then if Y then Z else A else B |
| 03:09.21 | brlcad | multivariate states |
| 03:09.54 | pra5ad | hrm |
| 03:10.01 | brlcad | what's totally unrepresentable, though, is parallel dependent evaluation |
| 03:10.14 | brlcad | where flowcharting falls apart |
| 03:10.21 | brlcad | and that will eventually be needed |
| 03:11.03 | pra5ad | so why not get a bunch of ppl together and discuss this once and for all |
| 03:11.21 | pra5ad | lol |
| 03:11.25 | brlcad | i should just write a report or something |
| 03:11.35 | pra5ad | i swear noone knows wtf is going on |
| 03:11.38 | pra5ad | how codes work |
| 03:11.41 | pra5ad | ... sigh |
| 03:11.48 | brlcad | discussions just turn into long drawn out nothings |
| 03:15.23 | brlcad | howdy mahesh :) |
| 03:15.43 | mahesh | hey, had some questions for you |
| 03:16.31 | brlcad | ask away |
| 03:17.15 | mahesh | instead of trying to plugin mpi stuff into the existing code, do you think I should just write a completely new one? |
| 03:18.09 | mahesh | so that i wont have to worry about those complicated stuff done to handle multiprocessors |
| 03:18.56 | pra5ad | hmm where would u need iterative logic? |
| 03:19.02 | brlcad | initial gut feeling is that you should go with the existing as it takes care of quite a lot of details that you'd otherwise have to handle (like setting up the view grid, collecting results) |
| 03:21.39 | brlcad | pra5ad: strictly speaking, you don't need iterative when asking a single node to evaluate (though you certainly could and one could argue that is the natural way to describe them) |
| 03:22.03 | brlcad | they could all be recursively evaluated, functionally, etc too |
| 03:22.27 | brlcad | it's a state machine, we're querying state at different conditions |
| 03:22.29 | pra5ad | u cant mimic this using probabilities? |
| 03:22.45 | pra5ad | keep maintaining the tree |
| 03:23.08 | brlcad | depends what "this" is |
| 03:23.15 | pra5ad | iterative logic |
| 03:23.30 | brlcad | much yes -- that's what's done now |
| 03:23.44 | pra5ad | whats missing |
| 03:23.58 | brlcad | there are plenty of states that do not fit well like that though |
| 03:24.44 | brlcad | parallel dependent evaluation is an easy one that comes to mind just because it doesn't even fit into a static state machine (which all our ft's are) |
| 03:25.21 | brlcad | I could try to fake it with probabilities, but there are easily cases where the probabilities would be either meaningless or flat out wrong |
| 03:26.20 | brlcad | and regardless, it's still a matter of whether or not that even is a "natural" way to describe the state and state failures |
| 03:26.34 | pra5ad | u'll have to explain 'parallel dependent evaluation' tomorrow |
| 03:26.50 | brlcad | seems rather natural to say "if this happens followed by this and this, then that happens some of the time" |
| 03:27.53 | brlcad | think of some parallel code executing with interdependencies between them, locking whatever |
| 03:28.32 | brlcad | try to flowchart the logic |
| 03:28.32 | pra5ad | ah time dependancy |
| 03:29.15 | brlcad | time/state/events/pcdh's/pkcurves/whatever |
| 03:31.37 | brlcad | mahesh: if it's getting too confusing, please let me know :) I'm sure something can be done to help by either making a simplified rt with some aspects removed, or by explaining |
| 03:32.28 | brlcad | mahesh: if you really think starting fresh will help, I'll still support you, but I do think you'll end up doing more work in the long run and we'd still want to merge the stuff in with rt eventually |
| 03:40.15 | brlcad | mahesh: perhaps a good starting point would be to "make your own" raytracer by copying rt's existing front-end (cp src/rt/view.c src/rt/viewparallel.c) and adding it to the build (edit src/rt/Makefile.am) as 'rtp' or 'rt2' or something so you can make changes and remove stuff and still compare to the original |
| 03:40.48 | brlcad | i could do that for you in just a few minutes, if you think it'd help |
| 03:50.57 | mahesh | that was one more thing i wanted to ask |
| 03:51.26 | mahesh | i am not that good with Makefile |
| 03:51.38 | mahesh | I want to compile my program with mpicc |
| 03:51.43 | mahesh | how do i do it? |
| 03:53.00 | brlcad | you should be able to override when you run make |
| 03:53.03 | brlcad | example: |
| 03:53.21 | brlcad | make CC=mpicc |
| 03:56.39 | mahesh | ok...got it |
| 03:56.40 | mahesh | now, |
| 03:56.54 | mahesh | do you remember the structure named server? |
| 03:58.38 | brlcad | vaguely, can look it up |
| 03:59.10 | mahesh | that actually stores information about each processor |
| 03:59.23 | brlcad | huh? |
| 03:59.29 | brlcad | not in rt, afaik |
| 03:59.34 | brlcad | maybe in remrt |
| 03:59.50 | mahesh | oops...wait a sec |
| 04:00.38 | brlcad | rt uses a resource structure .. named "resource" |
| 04:01.17 | brlcad | and one special one named rt_uniresource |
| 04:01.38 | mahesh | i am sorry...thats what i meant |
| 04:01.44 | brlcad | those allow for per-cpu storage of data |
| 04:01.56 | brlcad | that should be thread/processor safe |
| 04:02.38 | mahesh | should i use that structure? |
| 04:04.05 | brlcad | sure you could, or create your own struct resource array for the nodes |
| 04:04.54 | brlcad | i'd probably allocate your own for starters, just to keep it separate |
| 04:05.05 | mahesh | ok got it |
| 04:05.43 | brlcad | struct resource mydata[MAX_NODES_IN_CLUSTER]; |
| 04:05.59 | brlcad | or allocate dynamically with malloc, etc |
| 04:08.51 | mahesh | thats fine....i was more concerned about alll the fields in the resource structure |
| 04:09.58 | mahesh | i will go over again and ask you specific questions tomorrow |
| 04:10.18 | brlcad | you'll need to init each one in the array |
| 04:10.36 | brlcad | for (i=0; i < MAX_NODE_IN_CLUSTER; i++) { |
| 04:10.50 | brlcad | rt _init_resource( &mydata[i], i, rtip); |
| 04:10.53 | brlcad | } |
| 04:11.01 | mahesh | yeah yeah...i get those stuff |
| 04:12.12 | mahesh | i wonder when i will start coding some stuff! |
| 04:15.49 | brlcad | mahesh: curious, what do you need the resource structures for? |
| 04:17.05 | brlcad | if you mimic/replace the bu_parallel interface, you can use whatever structure/pointer you like |
| 04:18.15 | mahesh | i wanted to follow the same way it is done currently. Now it is done for multiprocessors...i was planning to do for nodes |
| 04:18.27 | mahesh | thats why i thought i could use the resource structure |
| 04:20.11 | mahesh | you are spot on... replacing bu_parallel is what i should do |
| 04:24.43 | brlcad | if you can replace bu_parallel dead on by only modifying libbu and librt, you'd actually add distributed capabilities across dozens and dozens of apps :) |
| 04:25.26 | mahesh | every time you say such things, i get so excited |
| 04:26.40 | mahesh | but till date, its all been flop from me |
| 04:55.20 | pra5ad | u cant be serious.. migw-g++ doesnt recognize enums.. |
| 05:00.59 | brlcad | sure it does |
| 05:01.21 | brlcad | i've compiled brl-cad with it |
| 05:01.35 | brlcad | and there's at least one enum in there somewhere I think |
| 05:03.30 | pra5ad | ahh there's an identifier that passes thru the linux gcc version |
| 05:03.38 | pra5ad | that the cygwin one has reserved apparently |
| 05:32.32 | pra5ad | =~( |
| 07:24.05 | *** join/#brlcad Guu` (i=guu@myth.gibbscam.com) | |
| 08:47.19 | *** join/#brlcad clock_ (n=clock@233.61.3.213.cust.bluewin.ch) | |
| 09:01.51 | *** join/#brlcad clock_ (n=clock@233.61.3.213.cust.bluewin.ch) | |
| 10:05.42 | *** join/#brlcad docelic (n=docelic@195.246.23.200) | |
| 13:59.52 | *** join/#brlcad Inktvlek (i=HydraIRC@81-171-3-223.dsl.fiberworld.nl) | |
| 14:00.08 | Inktvlek | Hello |
| 14:00.24 | Inktvlek | I was wondering if there is any news on windows builds |
| 14:00.44 | Inktvlek | I couldn't find it on the sf page |
| 14:02.39 | brlcad | hello |
| 14:02.53 | brlcad | there's an alpha build available if you're interested in testing it |
| 14:03.13 | Inktvlek | yes that's ok with me |
| 14:03.27 | Inktvlek | where can I find it? |
| 14:03.39 | brlcad | if you run into any issues, please report them back here to me |
| 14:03.45 | brlcad | http://ftp.brlcad.org/private/BRL-CAD_win32_20050916.zip |
| 14:03.47 | Inktvlek | I will |
| 14:04.26 | Inktvlek | thank you! |
| 14:04.27 | brlcad | there will likely be a beta next month that gets posted to the site |
| 14:04.46 | brlcad | http://brlcad.org under the Documents section for tutorials/documentation |
| 14:05.42 | *** join/#brlcad Twingy_ (n=justin@pcp0011647505pcs.aberdn01.md.comcast.net) | |
| 14:17.41 | *** part/#brlcad Inktvlek (i=HydraIRC@81-171-3-223.dsl.fiberworld.nl) | |
| 16:50.49 | ``Erik | *burp* |
| 16:57.50 | brlcad | *burp* |
| 17:17.21 | Twingy_ | *meow* |
| 17:33.38 | ``Erik | don't you mean *flip* ? |
| 17:33.51 | Twingy_ | *barf* |
| 17:34.23 | ``Erik | http://support.microsoft.com/default.aspx?scid=kb;en-us;Q325038 |
| 17:34.38 | ``Erik | http://support.microsoft.com/default.aspx?scid=kb;en-us;Q172653 |
| 18:42.20 | *** join/#brlcad DTRemenak (n=DTRemena@DHCP-170-143.caltech.edu) | |
| 18:51.22 | *** join/#brlcad Guu (i=guu@myth.gibbscam.com) | |
| 19:37.04 | *** join/#brlcad clock_ (n=clock@84-72-93-244.dclient.hispeed.ch) | |
| 20:20.29 | *** join/#brlcad raz (n=raz@pool-138-88-91-62.res.east.verizon.net) | |
| 21:40.37 | *** join/#brlcad Erroneous (n=DTRemena@DHCP-170-143.caltech.edu) | |