| 00:57.14 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 02:16.55 | Notify | 03BRL-CAD:ejno * 65176 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: fixes |
| 02:32.05 | Notify | 03BRL-CAD Wiki:Joseareyes24 * 0 /wiki/User:Joseareyes24: |
| 02:35.01 | *** join/#brlcad infobot (ibot@rikers.org) |
| 02:35.01 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || Congrats to all GCI 2014 winners Peter & Marc! || Congratulations to our 12 GSoC students! || Don't ask if someone is here, just ask your questions and wait for a response. ;-) |
| 03:22.56 | *** join/#brlcad ulty (~ofnlut_@2601:a:6680:ee3:c17b:97a6:b414:de00) |
| 03:37.29 | *** join/#brlcad Gurwinder (3b5beb47@gateway/web/freenode/ip.59.91.235.71) |
| 03:49.17 | Gurwinder | I make a ellipse and type "l myellipsename". It shows, A rotation angle, B rotstion angle, C rotation angle. Does it means angle with x, y and z axis? |
| 05:34.59 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-sjnfabjxwleoqzeb) |
| 07:29.10 | *** join/#brlcad teepee-- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 09:00.25 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) |
| 11:07.37 | starseeker | brlcad: eh? most of the core docbook logic lives in misc/CMake/Docbook.cmake and the corresponding tool invocation templates (xmllint.cmake.in, xsltproc.cmake.in, etc.) in misc/CMake |
| 11:11.05 | starseeker | brlcad: the books use some extra custom stylesheets for PDF to take advantage of the work Tom did, and there is a bit of toplevel resource management in doc/docbook/CMakeLists.txt and the fop.xconf and log4j files, but other than that the majority of the files are about listing xml and image files and calling the macros |
| 11:13.36 | starseeker | man5/en/CMakeLists.txt has some extra bits due to our generating some xml content from "normal" programs built in the primary system build, and if we move to getting all option docs from running programs to generate them things will get messy, but at the moment I thought things were reasonably sane considering the inherent complexity of the DocBook "build" process |
| 11:14.57 | starseeker | isn't saying things can't be improved - they can always be improved - but I didn't have anything burning in my queue on re-engineering the DocBook CMake |
| 11:15.22 | starseeker | willing to change that, but could use some suggestions on how you would like things to look/act :-) |
| 11:20.57 | dracarys983 | starseeker: Can you give me some pointers on how do I understand the implementation part for gqa and rtweight? |
| 11:22.09 | dracarys983 | I have tried this till now : https://docs.google.com/document/d/1qmyaHOuNskAxdgw8iA8vTIl8iYLCxOEwhTCHkvXUjbA/edit?usp=sharing |
| 13:13.53 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 13:16.11 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 13:52.12 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:04.03 | *** join/#brlcad vasc (~vasc@bl13-97-128.dsl.telepac.pt) |
| 14:06.46 | brlcad | starseeker: I think the problem is your caveat of "most" .. there's definitely necessary BRLCAD_EXTRADOCS_* statements in doc/docbook cmakefiles |
| 14:07.00 | brlcad | so to add a new output formatter, you have to edit at least those three places |
| 14:08.02 | brlcad | not a big deal, just a little sprawling .. I'm not even sure there IS an easy way to encapsulate it better without pushing it all into doc/docbook |
| 14:10.05 | brlcad | I just remember you talking way back when (a couple years ago) when you were actively working on it, about encapsulation improvements you had intended and things you were going to come back and fix |
| 14:10.43 | brlcad | maybe I'm confusing it with other cmake cleanup intentions ;) |
| 14:14.22 | brlcad | ``Erik: named seems to be very unhappy... I had to turn it off because of a slew of SERVFAIL responses coming in |
| 14:14.40 | brlcad | and REFUSED |
| 14:31.16 | *** join/#brlcad joevalleyfield (~joevalley@66-118-151-70.static.sagonet.net) |
| 14:48.35 | Notify | 03BRL-CAD:carlmoore * 65177 brlcad/trunk/src/util/bwstat.c: use the DECLARATIONS to initialize variables; simplify the sum calculation (comment about non-use of 'else') |
| 15:12.00 | *** join/#brlcad d3r1ck (~root@195.24.220.134) |
| 15:12.45 | *** part/#brlcad d3r1ck (~root@195.24.220.134) |
| 15:14.42 | brlcad | heh, root user |
| 15:16.25 | *** join/#brlcad terrywen (~twen6@pool-71-97-144-189.bltmmd.fios.verizon.net) |
| 15:17.45 | dracarys983 | brlcad: Any pointers you can give on understanding the implementation of gqa and rtweight? |
| 15:18.13 | dracarys983 | I have tried this till now : https://docs.google.com/document/d/1qmyaHOuNskAxdgw8iA8vTIl8iYLCxOEwhTCHkvXUjbA/edit?usp=sharing |
| 15:18.16 | brlcad | dracarys983: on understanding the implementation, what would you like to know? |
| 15:18.23 | brlcad | can't get to google docs atm |
| 15:18.52 | brlcad | have you read through this: http://brlcad.org/wiki/Example_Application |
| 15:19.05 | dracarys983 | Nope I haven't |
| 15:19.13 | brlcad | that is the basic structure of all our ray-tracing applications |
| 15:19.33 | brlcad | that shoots a single ray and uses a callback mechanism to handle hits and misses |
| 15:19.47 | dracarys983 | Oh nice. :D |
| 15:19.50 | brlcad | it fundamentall underpins both gqa and rtweight |
| 15:20.05 | brlcad | rtweight shoots a 2D grid using that interface |
| 15:20.19 | brlcad | gqa shoots 3 axis-aligned 2D grids using that interface |
| 15:20.40 | dracarys983 | Great. That will be helpful :) |
| 15:20.41 | brlcad | probably not, but might be helpful to you too vasc |
| 15:21.05 | dracarys983 | I was actually trying to look at gqa.c's ged_gqa() today |
| 15:21.27 | dracarys983 | Couldn't make a lot out of it. So, I needed help. This is awesome :) |
| 15:21.32 | brlcad | vasc: you'll also want to look at http://brlcad.org/wiki/Developing_applications especially the first link that explains the RTUIF |
| 15:22.30 | brlcad | vasc: you mentioned yesterday about view_eol not being used ... except it is used, just not by that application -- the rtuif is an application callback interface shared by a dozen or more different applications, so while rt doesn't need to use it, others do/might/can |
| 15:22.51 | brlcad | dracarys983: glad to help |
| 15:23.23 | vasc | hm but that code was on rt |
| 15:23.25 | brlcad | dracarys983: most of gqa's complexity is actually in the complex book-keeping it needs in order to calculate volume/overlaps/centroids/moments, etc |
| 15:23.27 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:23.36 | vasc | maybe its set as a callback elsewher |
| 15:23.41 | brlcad | right |
| 15:23.47 | brlcad | it has to provide it, just nothing to do |
| 15:24.44 | brlcad | the view*.c files have to define a set of functions for the "front end" of the RTUIF, that being one of them |
| 15:24.57 | vasc | i'm still trying to do something as bare bones as possible |
| 15:25.19 | dracarys983 | brlcad: Roger that. I did notice a lot of huge data structures like rt_i and region and resource being used. |
| 15:25.55 | brlcad | the back end just calls them .. if there was a registration table or something, it could have been left off but meh not really a problem to stub an empty -- there are other ways I'd refactor that code if motivated |
| 15:26.45 | brlcad | dracarys983: yes, the example talks about those |
| 15:26.49 | vasc | the code as lots of kludging because it doesn't have a mask saying which parts are background and which aren't |
| 15:27.03 | vasc | so it basically knows its the background if the color is the bg color |
| 15:27.40 | brlcad | dracarys983: you might also like to read the first one on http://brlcad.org/wiki/Developing_applications if you want a little more understanding of those structures or just ask questions as they come to mind |
| 15:28.02 | brlcad | vasc: yep |
| 15:28.07 | vasc | and perfect black is yet another special color used for when the canvas wasn't used yet |
| 15:28.29 | brlcad | vasc: you do recall me saying that this is literally a second-generation ray trace implementation that has evolved over three decades? :) |
| 15:28.37 | vasc | because of that i'm going to have to do all these framebuffers read i wouldn't need to do otherwise |
| 15:28.57 | brlcad | it was like the third or fourth computer ray tracer imlementation (ever) ;) |
| 15:29.06 | dracarys983 | brlcad: Right now there aren't much questions as I haven't studied them in much detail. I'll get back once I read through these amazing wikis :) |
| 15:29.29 | vasc | i'll figure something out |
| 15:29.38 | brlcad | that said, not an excuse for not having a mask -- just nobody has bothered / needed it to date |
| 15:31.24 | vasc | well its ok i can handle it like this. its just a bit special cased |
| 15:33.04 | brlcad | adding alpha to libfb and rt has been on our todo for a long time |
| 15:33.25 | vasc | i'm going to try to simplify rt_shootray next |
| 15:33.59 | brlcad | what's the long-term plan? |
| 15:34.37 | vasc | well after i make this bare bones c version, i'll try to remove the serial bottlenecks and branches out of it more |
| 15:34.41 | brlcad | I mean you're going to have this widdled down to a bare skeleton of what it was, and then restructure |
| 15:34.42 | vasc | and after that i'll port it to opencl |
| 15:34.54 | vasc | and then i'll start adding things back |
| 15:35.18 | brlcad | but then what? how is that going to get rolled back in, or will that even be possible at that point? |
| 15:35.36 | vasc | well |
| 15:35.50 | vasc | this sound be a user option at runtime |
| 15:36.06 | brlcad | ending up with a completely separate ray tracer that proves the concept is certainly a conceivable step, but ideally we merge the concepts into one |
| 15:36.55 | vasc | well one of the things i want to add eventually, before the opencl port, is to be able to merge results from the c rt code with the opencl rt code |
| 15:37.19 | vasc | like when i call rt_shootray i get some results in the opencl side and some in the c side and then i merge them |
| 15:37.53 | vasc | if the two sides didn't communicate you would only be able to render opencl accelerated primitives and i want to render ALL primitives |
| 15:37.54 | brlcad | the opencl code will almost certainly need to bypass rt_shootray() |
| 15:38.06 | brlcad | calling instead rt_shootrays() or something similar |
| 15:38.26 | vasc | i'll get segments from both sides and then merge the segments somehow |
| 15:38.29 | vasc | at least that's the plan |
| 15:39.25 | vasc | let see what i wrote in the planning |
| 15:39.41 | brlcad | you were somewhat vague ;) |
| 15:39.55 | brlcad | but then this is a research project |
| 15:40.00 | vasc | its no use being specific when the details are unknown yet |
| 15:40.13 | vasc | i could write something and be completely wrong about it |
| 15:40.17 | brlcad | that's why we didn't call you out on it ;) |
| 15:40.37 | brlcad | you'll notice your proposal was easily the shortest of them all (possibly the shortest ever) |
| 15:40.46 | vasc | yeah i did |
| 15:40.58 | vasc | i don't like planning in too fine detail when i don't know the details |
| 15:41.02 | vasc | its a waste of time |
| 15:41.32 | brlcad | normally more research would have been expected as part of the proposal development (prior to selection, prior to bonding), but this project is quite unique in its complexity and advanced concepts |
| 15:41.47 | vasc | well i did spend some days reading the code |
| 15:42.01 | vasc | but only as i started actually coding it some things became more evident |
| 15:42.21 | brlcad | sure, that's my point -- your target is 10x harder and expecting 10x more research prior to acceptance would have been unreasonable on our part |
| 15:42.44 | brlcad | so a proposal that is 1/10th in length is a reasonable expectation ;) |
| 15:42.57 | brlcad | lots more unknowns to sort out and directions that can be taken |
| 15:43.46 | vasc | well right now i managed to simplify the ray generation and writing the results to the image buffers |
| 15:43.51 | vasc | which is the 'easy' part |
| 15:43.55 | brlcad | part of me still thinks it might be worthwhile to limit focus on just dispatch or just spatial partitioning or just boolean weaving |
| 15:44.12 | vasc | yeah sure but the problem is it won't be fast if we just do that |
| 15:44.25 | brlcad | sure, but we're cool with baby steps ;) |
| 15:44.43 | brlcad | remember, we've been around for decades .. what's another year? :) |
| 15:45.03 | vasc | i'll continue on this path. if its taking too long i'll change the plan |
| 15:45.35 | vasc | i wanted to understand the whole problem so i can do something about it |
| 15:45.38 | brlcad | sounds reasonable to me too, there isn't a wrong answer here |
| 15:46.02 | vasc | i've worked on first hit ray tracers a lot but this one is a bit different |
| 15:46.09 | brlcad | I just want to make sure we end up with something production usable and integrated (even if it has no ultimate impact on performance due to other sections of the pipeline) |
| 15:46.31 | vasc | well it shouldn't be too hard to add back the features i removed so far |
| 15:46.46 | vasc | its basically different initialization sequences and things like that |
| 15:47.09 | brlcad | getting accelerated gridded spatial partitioning in there would almost certainly have a big impact on performance |
| 15:47.13 | vasc | the code as is has a lot of branches because of that. ideally we should just change that code so that there are no branches |
| 15:47.29 | vasc | i hope so |
| 15:47.31 | brlcad | the recursive BSP is has now is tuned, but nowhere near coherent |
| 15:47.46 | brlcad | there actually is a grid method in there (nugrid, you may have seen it) |
| 15:47.55 | vasc | yes |
| 15:48.04 | vasc | i actually based my phd work on a grid like that one |
| 15:48.06 | brlcad | but it was never completed and that was like the first ever implementation of gridded spatial partitioning |
| 15:48.26 | brlcad | 20 or so years ago |
| 15:48.50 | vasc | there are always these implementation details when you do spatial partitioning that can cause rendering errors |
| 15:48.59 | vasc | like trying to shoot rays at axis aligned planes |
| 15:49.24 | vasc | its probably going to need some tweaking |
| 15:49.51 | vasc | usually when i'm doing research we kind of gloss over 'little' details like that |
| 15:50.05 | vasc | which isn't gonna cut it here |
| 15:50.15 | brlcad | on a separate topic and almost certainly on the fringe of scope for your project, there are several intentions in mind for defining a SAH that an accelerated kd/bsp/grid can use |
| 15:50.25 | vasc | yeah |
| 15:50.31 | vasc | i thought of that and read some papers |
| 15:50.33 | brlcad | in solid modeling terms SAH is bogus nomenclature |
| 15:50.42 | vasc | and i'm thinking about which acceleration structure is the best |
| 15:50.47 | brlcad | as SA is really only good for approximating mesh complexity |
| 15:50.49 | vasc | its probably going to be a bvh i think |
| 15:51.01 | vasc | because of the csg ops |
| 15:51.30 | brlcad | for us, SAH is probably generalized to "OCH" object complexity heuristic |
| 15:51.40 | brlcad | not just the csg ops, that only affects COMB objects |
| 15:51.55 | brlcad | different prims have different calculation characteristics |
| 15:52.15 | vasc | yes some are more complex to intersect than others that's an interesting observation |
| 15:52.17 | brlcad | ell vs arb8 is something like 10 ops vs 100 ops |
| 15:52.26 | brlcad | vs torus is something like 2000 ops |
| 15:52.36 | vasc | well arb8 when i looked at it looked kind of strange |
| 15:52.40 | brlcad | or better, 1000-10000 |
| 15:52.51 | vasc | i expected a parallellipiped intersection but no that one |
| 15:52.59 | brlcad | each primitive has different intrinsic complexity |
| 15:53.57 | vasc | there are faster intersection routines when the planes are parallel |
| 15:54.10 | vasc | arb8 is slow when you're using boxes |
| 15:54.18 | brlcad | sure but then is doing the calcs to know they're parallel faster? :) |
| 15:54.49 | vasc | well yeah but that's because the user primitives are like this |
| 15:54.59 | brlcad | our arb8's are a generalized implementation that holds for arb8/arb7/arb6/arb5 and is exceptionally validated in depth for desired behavior |
| 15:55.10 | vasc | i don't know which kind of most commonly modelled solids they want |
| 15:55.51 | brlcad | when you're using boxes, arb8 turns into the rpp special case |
| 15:55.57 | brlcad | which has different evaluation |
| 15:56.35 | brlcad | just like how ell turns into the sph special case |
| 15:57.06 | vasc | oh so rpp is the boxes |
| 15:58.39 | brlcad | right paralellpiped ;) |
| 16:05.14 | vasc | some things about the intersection code are going to be a real problem i was talking about that with Stragus the other day |
| 16:05.28 | vasc | like you guys use these linked lists to store the ray segments for the intersections |
| 16:05.33 | vasc | dynamic linked lists |
| 16:06.00 | vasc | opencl doesn't support gpu side dynamic memory allocation |
| 16:11.14 | vasc | so what i said was that i was going to refactor the code to process many rays in parallel in c |
| 16:11.20 | vasc | the thing is it already does that |
| 16:11.34 | vasc | with scanlines |
| 16:14.59 | vasc | crickey |
| 16:18.18 | vasc | is there any way to disable the acceleration structures? |
| 16:18.20 | vasc | hmmm |
| 16:18.27 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 16:19.51 | vasc | its really hard to wrap around this thing |
| 16:22.34 | brlcad | if we didn't use linked lists, you probably wouldn't have been able to propose this as project |
| 16:22.57 | brlcad | there was absolutely no expectation that you'd be able to leverage existing containers in any way .. |
| 16:23.15 | brlcad | they're not just incoherent, but that's their biggest failing for acceleration |
| 16:25.10 | vasc | yeah |
| 16:25.27 | vasc | man that shoorray code is complicated |
| 16:25.33 | vasc | starts his chainsaw |
| 16:26.27 | brlcad | yep, and trivial compared to boolweave |
| 16:27.38 | brlcad | when I first started working on brl-cad, I attempted refactoring boolweave twice |
| 16:28.59 | brlcad | my first attempt took a week and produced wildly different results even though i *thought* my changes were equivalent constructs |
| 16:29.03 | vasc | well i would like to know how it would look like without any BSP stuff in it |
| 16:29.09 | vasc | oh |
| 16:29.29 | vasc | that's interesting |
| 16:29.41 | brlcad | couple years later, I tried again .. this time I seemingly got the logic transformation right and the resulting code (while more readable) was a solid 25% slower :) |
| 16:30.07 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 16:30.35 | brlcad | it's using really old school C tricks, complex gotos, and LOTS of very sensitive floating point handling |
| 16:30.38 | sofat | brlcad, starseeker I got this error |
| 16:30.43 | sofat | make[2]: *** No rule to make target `doc/docbook/articles/../resources/brlcad/wordpress.xml', needed by `share/doc/html/articles/en/about.php'. Stop. |
| 16:30.43 | sofat | make[1]: *** [doc/docbook/articles/en/CMakeFiles/about_article_html.dir/all] Error 2 |
| 16:30.53 | sofat | any solution for this ? |
| 16:30.56 | vasc | i had an issue like that once when i was rewriting the freeciv game rule inference engine |
| 16:31.20 | vasc | to be more generic |
| 16:31.44 | vasc | in the end i just rewrote the whole thing while pretending i was a compiler i.e. not thinking too much about it |
| 16:31.45 | vasc | and it worked |
| 16:32.15 | brlcad | today if I were to attempt it again, I'd buffer up all partitions into arrays, so I can do the complex testing on them in massive batches |
| 16:32.51 | brlcad | almost certainly can't do it branch-free, but instead evaluate all possible branches and fold the desired solutions |
| 16:33.52 | brlcad | sofat: that error is clearly because of changes you've made so it means you're missing a bit of logic .. follow the BRLCAD_EXTRADOCS_HTML sections and make sure you have a corresponding one for _WORDPRESS for *all* of them |
| 16:34.08 | vasc | and it worked |
| 16:34.11 | vasc | oops |
| 16:34.14 | brlcad | :) |
| 16:34.16 | vasc | wrong window |
| 16:34.21 | brlcad | it worked |
| 16:34.54 | vasc | lets see |
| 16:35.19 | brlcad | the theory in boolweave is actually pretty simple .. it's crazy optimizations |
| 16:35.33 | brlcad | one of our devs reimplemented it in java in like 100 lines of code |
| 16:35.43 | brlcad | ran like 100x slower, but the proof was there |
| 16:36.06 | brlcad | (this was maybe 10 years ago) |
| 16:36.29 | vasc | we had some issues like that with our AI code. but only worse. |
| 16:36.45 | vasc | the freeciv AI was written all by one guy and he used variables like a,b,c,d,e,f |
| 16:36.51 | vasc | and then he vanished |
| 16:37.23 | vasc | some guys wanted to rewrite it and thought because the code was like that that the implementation was simple and easy to replace |
| 16:37.25 | vasc | but not so |
| 16:37.36 | vasc | that guy was a genius who wrote unreadable code that's all |
| 16:38.49 | vasc | man they had a really hard time figuring out what the variables were and what he was doing |
| 16:39.00 | vasc | i think they spent like a year or two reverse engineering his |
| 16:39.06 | vasc | THEN they started improving it |
| 16:39.38 | vasc | good thing i wasn't involved on that one |
| 16:41.46 | vasc | we never knew what happened to that ai guy |
| 16:42.49 | brlcad | you work much with blast007? |
| 16:43.59 | brlcad | geniouses that can't communicate effectively are fairly worthless imho |
| 16:44.02 | vasc | don't know the guy |
| 16:44.14 | vasc | well we didn't have an AI before that guy did his |
| 16:44.17 | brlcad | I think he worked on freeciv for a while |
| 16:44.19 | brlcad | is all |
| 16:44.52 | vasc | does he have a real name? |
| 16:45.11 | vasc | i don't know that handle |
| 16:45.20 | brlcad | no worries |
| 16:45.42 | brlcad | i might even be mixing up names |
| 16:45.50 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 16:46.07 | brlcad | one of our bz devs worked on a couple other games for a while |
| 16:46.44 | brlcad | led that project for about 5 years through hayday |
| 16:47.33 | vasc | i remember hearing about that game a lot |
| 16:47.50 | vasc | but i was never that good at games which need quick reflexes |
| 16:48.58 | *** join/#brlcad vasc (~vasc@bl13-97-128.dsl.telepac.pt) |
| 16:49.08 | vasc | and i get motion sickness easily |
| 16:49.42 | vasc | i can't play an fps for more than 2 minutes without getting a headache |
| 16:50.36 | vasc | i kind of get how the rt shootray works |
| 16:51.00 | vasc | you start by finding the bounding box of the scene and test if you intersect it if you don't you find which cell you're in |
| 16:51.16 | vasc | and then see if you intersect what's inside |
| 16:51.21 | vasc | and then it recurses or something |
| 16:51.38 | vasc | what i don't get is what all these lists are used for and how they're build |
| 16:51.42 | vasc | built |
| 16:51.46 | vasc | i need to read this more slowly |
| 16:53.11 | vasc | not to mention i don't get much of where the normals and computed and the color is calculated either |
| 16:56.31 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 16:58.21 | vasc | bleargh |
| 16:58.40 | sofat | brlcad, I solve |
| 16:58.49 | sofat | problem |
| 17:02.15 | vasc | ah i see it update the color when it calls the a_hit callback. brilliant |
| 17:02.16 | vasc | sigh |
| 17:24.14 | *** join/#brlcad deepak (~chatzilla@122.173.238.230) |
| 17:40.54 | Notify | 03BRL-CAD:n_reed * 65178 (brlcad/branches/brep-debug/src/libbrep/debug_plot.h brlcad/branches/brep-debug/src/libbrep/intersect.cpp): make some DebugPlot members public for ad hoc plotting |
| 17:46.36 | Notify | 03BRL-CAD:n_reed * 65179 brlcad/branches/brep-debug/src/libbrep/intersect.cpp: fix a mistake in my r64385 that caused some bad linking of overlap curves |
| 17:59.24 | *** join/#brlcad ries (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 17:59.25 | vasc | uh... |
| 18:02.06 | vasc | can't figure out where the shader is set |
| 18:10.55 | *** join/#brlcad Milinda (7086390d@gateway/web/freenode/ip.112.134.57.13) |
| 18:11.49 | ``Erik | brlcad: huh, servfail and refused? and breadcrumbs to a cause? all I did was install dns/isc-bind910, point it to /etc/named and fire it up. Any indication if it's a config issue or an attack attempt? |
| 18:15.26 | ``Erik | dracarys983: if you're looking for an absolute minimal way to fire a ray and see results, you might check out 'rtcmp' (it's project under the BRL-CAD umbrella, instead of brlcad/code/brlcad/trunk it'd be brlcad/code/rtcmp/trunk |
| 18:18.26 | ``Erik | vasc: whuddya mean by 'where the shader is set'? O.o |
| 18:18.41 | Milinda | Hi, In dm-generic.c file we have, |
| 18:18.43 | Milinda | #ifdef DM_X # if defined(HAVE_TK) case DM_TYPE_X: return X_open_dm(interp, argc, argv); # endif #endif |
| 18:19.11 | vasc | well i was trying to simplify the shading code best i could but |
| 18:19.26 | vasc | it calls this callback and i can't figure out where its set |
| 18:19.54 | Milinda | So which header files do I have to include before use the method X_open_dm(interp, argc, argv) |
| 18:19.56 | Milinda | ? |
| 18:20.30 | ``Erik | Milinda: I think the dm.h pulls the necessary headers for you? |
| 18:21.20 | ``Erik | vasc: shaders are executed by the hit method, and it yanks a glob of info out of the mater for the region, iirc... the 'shader' could actually be a tree of shaders |
| 18:21.33 | ``Erik | and probably plugged in with function pointers |
| 18:21.40 | *** join/#brlcad terrywen (~twen6@pool-71-97-144-189.bltmmd.fios.verizon.net) |
| 18:22.30 | ``Erik | shaders actually live in liboptical, if that helps the hunt |
| 18:23.01 | ``Erik | if you're looking for the code path, you might set a breakpoint inside of a shader, run an rt, then look at the backtrace |
| 18:23.08 | vasc | man this code is really hairy |
| 18:23.19 | vasc | hm |
| 18:24.00 | ``Erik | decades of "stop this useless cleaning and just add the feature we want"... |
| 18:24.01 | vasc | i guess we'll just do the lighting on the cpu for now then |
| 18:24.23 | vasc | its got loops inside loops inside loops |
| 18:24.30 | vasc | with lights and things |
| 18:24.36 | ``Erik | :) ayup |
| 18:25.22 | ``Erik | do recall that it was originally architected for a vax11/780 running bsd43. The hw and os were radically different than modern stuff |
| 18:25.27 | Milinda | Erik: Thanks for the tip but I have already included the dm.h file |
| 18:26.16 | Milinda | Erik: The problem is X_open_dm(interp, argc, argv) function crashes ? Do you know why? |
| 18:26.26 | ``Erik | Milinda: you can always look at the errors and start adding headers to kill each one... tk.h might be enough? |
| 18:26.59 | ``Erik | "crashes"? what exactly does that mean? and is it pointed to a valid X server? |
| 18:27.01 | Milinda | Erik: I am getting run time errors :( |
| 18:27.34 | Milinda | Why X_open_dm(interp, argc, argv) crashes without creating the dm window? |
| 18:28.54 | ``Erik | if it actually crashes (like a segfault, pagefault, sigill, etc), the X server probably aborts the window request due to a lost connection |
| 18:29.37 | Milinda | Erik: Can you please direct me to a sample code which to create display manager window? I am working on this for a week now :) |
| 18:30.02 | Milinda | Erik: Okay Thanks for the tip. I think it is a segfault. So how can I fix it? |
| 18:30.51 | ``Erik | I don't know if there is any good standalone dm code... if it's a segfault, run it in gdb and look at the crash :D |
| 18:31.45 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 18:32.14 | ``Erik | if you don't know gdb, it's a handy thing to learn... there are gui front-ends (a couple older ones are ddd and xxgdb), but knowing the cli gdb can be very handy in some situations |
| 18:33.16 | Milinda | Erik: Thanks for the help I will try that. :) If you have some link to dm window creation example please send it to me :) |
| 18:35.17 | Notify | 03BRL-CAD:starseeker * 65180 (brlcad/trunk/include/bu/opt.h brlcad/trunk/src/libbu/opt.c): More simplification |
| 18:35.19 | ``Erik | Milinda: I haven't done much with libdm/libfb stuff, lurk and maybe brlcad, starseeker, nreed, etc might have some useful info for ya *shrug* good luck |
| 18:36.32 | ``Erik | goes back to unravelling a weird issue between NSURLConnection on iOS and a lumen based server not sharing json in a happy fashion O.o |
| 18:38.33 | Milinda | brlcad: Can you help me regarding this matter ? |
| 18:41.57 | vasc | i wonder how much time this spends shooting vs shading |
| 18:42.02 | vasc | the shading code seems really complex |
| 18:45.59 | Notify | 03BRL-CAD Wiki:202.164.45.208 * 8549 /wiki/User:Hiteshsofat/GSoc15/log_developmen: |
| 18:46.07 | ``Erik | vasc: profiling ftw, cha cha cha (fwiw, the bill paying consumer of BRL-CAD is mostly interested in the partition lists, ignoring shaders and things like pixels. Thus the separation and "seems good enough, don't touch it" smell of the shader stuff) |
| 18:57.25 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 19:09.56 | Notify | 03BRL-CAD Wiki:Terry.e.wen * 0 /wiki/User:Terry.e.wen: |
| 19:13.46 | brlcad | vasc: yeah, it does help to have quick reflexes with bz, but there is also a huge strategic component .. at least for certain game styles (CTF in particular) |
| 19:14.38 | brlcad | we were all over the place with crazy activity when I was leading it, kind of went downhill fast when I passed the reigns, but it's still got decent activity |
| 19:18.17 | brlcad | Milinda: did you look at plot3-dm.c ? |
| 19:19.26 | brlcad | vasc: shading rarely shows up on profile unless you apply really complex shaders that have logic of their own or turn on lots of light sources, etc |
| 19:19.39 | brlcad | basic phong shading is used 99% of the time |
| 19:20.27 | brlcad | at least for non-production renders .. production renders usually have tons of lights, textures, bumps, soft shadows, ambient occlusion, etc and are slow |
| 19:23.16 | Notify | 03BRL-CAD Wiki:Terry.e.wen * 8551 /wiki/User:Terry.e.wen: Blanked the page |
| 19:33.39 | vasc | i'll just use some dummy material then |
| 19:33.50 | vasc | for now |
| 19:51.00 | Notify | 03BRL-CAD:starseeker * 65181 (brlcad/trunk/include/bu/opt.h brlcad/trunk/src/conv/gcv/gcv.cpp and 3 others): Switch to just a plain argv array in the bu_opt_data struct to hold option arguments. |
| 20:01.42 | *** join/#brlcad sofat (~sofat@223.225.206.40) |
| 20:02.11 | Notify | 03BRL-CAD:starseeker * 65182 brlcad/trunk/src/libbu/opt.c: Make null termination explicit for clarity. |
| 20:05.40 | *** join/#brlcad andrei_il (~andrei@109.100.128.78) |
| 20:05.46 | sofat | brlcad, i am stuck in this i show you my settings which i am done. so please tell me where i am going wrong |
| 20:05.54 | sofat | docbook.cmake :-https://bpaste.net/show/1896d57b3f15 |
| 20:06.57 | andrei_il | starseeker: hello |
| 20:07.05 | sofat | Brlcad_summary.cmake:-https://bpaste.net/show/cfe3cb688183 |
| 20:07.58 | andrei_il | I started working on the simple .csg grammar using lemon and I encountered some issues |
| 20:08.00 | sofat | doc/docbook/CMakeLists.txt :- https://bpaste.net/show/ac9fdd05d371 |
| 20:08.49 | andrei_il | I posted my error and also the patch on the mailinglist |
| 20:08.51 | sofat | doc/docbook/articles/CMakeLists.txt :- https://bpaste.net/show/d8b22591676a |
| 20:09.57 | Notify | 03BRL-CAD:brlcad * 65183 brlcad/trunk/TODO: import geometry from ls-dyna .k keyword files |
| 20:10.08 | sofat | doc/docbook/article/en/CMakeLists.txt :- https://bpaste.net/show/f32c7f366d2f |
| 20:10.25 | andrei_il | When you have some time, I would appreciate if you could take a look and, if possible, help me solve the error |
| 20:10.38 | sofat | starseeker, if you know about this then please help me. |
| 20:11.56 | Notify | 03BRL-CAD:starseeker * 65184 (brlcad/trunk/include/bu/opt.h brlcad/trunk/src/conv/gcv/gcv.cpp): Make it easy to get the argv array of strings that weren't handled by the option parser, as well as the count of that array. |
| 20:15.37 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 20:24.04 | Notify | 03BRL-CAD:brlcad * 65185 brlcad/trunk/doc/CMakeLists.txt: stub in an initial file that outlines common steps that are taken during code review. these is literally just the list of all the things I think about when reviewing patches, so there's undoubtedly room for improvement. it's a step, though, towards better formalization and automation. |
| 20:25.43 | brlcad | sofat: I don't have time to wade through all of that right now ... it's too much and you don't have a simple question, you have a debugging problem |
| 20:26.29 | brlcad | I gave you a strategy -- look at every mention of _HTML and make sure you have an equivalent mention for _WORDPRESS if needed and that makes sense, has no mistake, etc |
| 20:26.37 | Notify | 03BRL-CAD:starseeker * 65186 brlcad/trunk/src/conv/gcv/gcv.cpp: Fix -i/-o options |
| 20:26.39 | brlcad | if you can't figure it out, back up |
| 20:28.10 | brlcad | mabye create a new BRLCAD_EXTRADOCS_TEST that does *nothing* different from _HTML -- if that doesn't work, you missed something |
| 20:28.20 | Notify | 03BRL-CAD:starseeker * 65187 brlcad/trunk/src/conv/gcv/gcv.cpp: print, then subtract |
| 20:29.28 | brlcad | you'll also want to make sure any files you change (e.g. the .xsl file) are not reference some place else (search for it) |
| 20:55.15 | *** join/#brlcad Shuhbam (6719e766@gateway/web/freenode/ip.103.25.231.102) |
| 21:07.40 | Notify | 03BRL-CAD:ejno * 65188 (brlcad/trunk/src/libgcv/conv/fastgen4/NOTES brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp): write regions to fg4 sections in the region-end function; enable export of primitives |
| 21:22.45 | Notify | 03BRL-CAD Wiki:Deekaysharma * 8553 /wiki/User:Deekaysharma/logs: |
| 21:30.25 | Notify | 03BRL-CAD:ejno * 65189 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: write colors for all regions |
| 21:40.13 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 21:46.45 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 21:54.04 | Notify | 03BRL-CAD Wiki:Konrado DJ * 8554 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 3 JUNE 2015 */ |
| 22:17.12 | vasc | what's the maximum size in amount of solids we can expect in a brl-cad .g file? |
| 22:17.37 | vasc | the rendering loop uses this bitmask per ray with numbits = num solids |
| 22:17.46 | vasc | i wonder how big that would be if i had one of those per pixel |
| 22:19.15 | ``Erik | um, tens or hundreds of thousands, maybe millions |
| 22:19.50 | vasc | that doesn't sound so good |
| 22:20.27 | vasc | this optimization probably needs to be done some other way then |
| 22:21.10 | ``Erik | there're quite a few 'real' models that are 10-100x the complexity of the included m35.g, if that helps |
| 22:21.26 | ``Erik | (m35 has more than 64 solids.) |
| 22:22.38 | ``Erik | m35 might even have more than 64 solids on a single shotline.. I know there're other models that easily have more than that on a shotline. |
| 22:23.04 | vasc | in a 1 mpixel image that would be 'just' 64 megabytes for that bitvector |
| 22:23.11 | vasc | which is ok |
| 22:23.27 | vasc | the GPU has a couple GBs |
| 22:23.40 | vasc | the question is |
| 22:23.57 | ``Erik | I don't think it's unheard of to shoot more than 6000x6000 for publication quality renders and posters and stuff |
| 22:24.21 | vasc | let's hope OpenCL supports virtual memory by then :-) |
| 22:24.43 | vasc | the thing is as it is now the code has one of those caches per thread |
| 22:24.47 | ``Erik | or ship 'postage stamp' work packets to the gpu |
| 22:24.56 | vasc | that's a bad idea |
| 22:25.03 | vasc | because it won't use the capacity properly |
| 22:25.22 | vasc | we want hundreds of threads in flight |
| 22:25.29 | vasc | thousands even |
| 22:25.39 | ``Erik | capacity of what, the cpu? if the postage stamps are, y'know, 256x256, no problem, right? |
| 22:25.43 | ``Erik | s/cpu/gpu/ |
| 22:25.51 | vasc | yes the gpu |
| 22:26.05 | vasc | oh i see your point |
| 22:26.09 | vasc | if its 6000x6000 |
| 22:26.10 | vasc | ok |
| 22:26.42 | vasc | i really hate that bitvector |
| 22:26.47 | ``Erik | 6kx6k is over 500 256x256 patches |
| 22:26.51 | vasc | in fact i hate any sort of context |
| 22:27.00 | ``Erik | and a 256x256 patch is 65536 pixels :) |
| 22:27.21 | ``Erik | heh, then opengl must annoy ya ;) |
| 22:27.30 | vasc | heard of vulkan? |
| 22:27.34 | vasc | they're gonna trash opengl |
| 22:27.40 | vasc | because it has too much context |
| 22:29.52 | vasc | hmm the lights look kind of off |
| 22:29.57 | vasc | maybe i should just turn them off |
| 22:29.58 | *** join/#brlcad KimK (~Kim__@ip68-102-30-143.ks.ok.cox.net) |
| 22:30.11 | vasc | i guess i'm not initializing the light position properly |
| 22:30.28 | ``Erik | hasn't khronos tried to replace ogl a couple times in the past? O.o |
| 22:30.55 | Stragus | Eh, OpenGL is going to stay with us for a long time |
| 22:31.29 | ``Erik | digs ogl, but cut his teeth on c64's (accumulator machines ftw!) and finds a certain elegance to automake... might be twisted :D |
| 22:31.41 | ``Erik | sup, mal :) |
| 22:31.51 | Stragus | I have nothing against a state machine. OpenGL's major flaw is that isn't low-level enough for modern hardware |
| 22:31.59 | Stragus | Hey Erik :) |
| 22:32.06 | vasc | yes there's a good chance they'll fail |
| 22:32.12 | ``Erik | Stragus: looked at apples "metal"? |
| 22:32.29 | Stragus | Glanced over it all: Metal, Mantle, Vulkan... |
| 22:32.38 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) |
| 22:33.28 | Stragus | They did a decent job at cleaning up the legacy OpenGL stuff, but it isn't low-level enough by design |
| 22:33.40 | Stragus | They'll probably "solve" this with a bunch of new extensions, again |
| 22:33.47 | Stragus | hugs CUDA |
| 22:36.06 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-sxljdvrgjotkxmzw) |
| 22:42.10 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 22:53.33 | Notify | 03BRL-CAD:starseeker * 65190 (brlcad/trunk/src/conv/gcv/gcv.cpp brlcad/trunk/src/libbu/opt.c brlcad/trunk/src/libbu/tests/opt.c): Start working on option handling based on validation routines instead of simple string checks. This will set the stage for supporting options with negative numbers, such as --num -9 |
| 22:58.28 | Notify | 03BRL-CAD Wiki:Bhollister * 8555 /wiki/User:Bhollister/DevLogJune2015: /* Thursday, June 4, 2015 */ |
| 22:59.48 | Notify | 03BRL-CAD Wiki:Bhollister * 8556 /wiki/User:Bhollister/DevLogJune2015: /* Thursday, June 4, 2015 */ |
| 23:09.53 | ``Erik | hehehe, opengl is so badass, it's extensions have extensions! |
| 23:11.01 | Stragus | :D |
| 23:47.35 | vasc | hmm we're gonna need opencl functions to compute normals too |
| 23:51.28 | vasc | bleargh |
| 23:51.31 | vasc | more weirdness |
| 23:51.54 | vasc | i'm gonna stop for the day i guess |
| 23:53.57 | Notify | 03BRL-CAD Wiki:85.246.97.128 * 8557 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |