| 00:00.05 | vasc | that's gonna be a problem with all these object types. but i'll think of a way |
| 00:00.17 | Stragus | Fetching as a texture is faster than direct memory access on some hardware, Nvidia Kepler for example |
| 00:00.31 | Stragus | (2.5 times faster on Kepler, no kidding) |
| 00:00.32 | vasc | oh it is? |
| 00:00.38 | vasc | interesting |
| 00:00.55 | vasc | i thought they had changed the L2 cache so it wasn't a problem anymore |
| 00:01.17 | vasc | then again |
| 00:01.25 | vasc | it should be doing streaming loads. |
| 00:01.25 | vasc | hm |
| 00:01.26 | Stragus | Later Kepler with CUDA compute 3.5 has ldg() to fetch read-only data through the texture cache, but compute 3.0 must "manually" use the texture cache |
| 00:01.43 | Stragus | Doesn't matter, texture cache is always faster on CUDA compute 3.0 |
| 00:02.03 | vasc | so i have to use that ldg() syscall? |
| 00:02.12 | Stragus | That only works on compute 3.5 |
| 00:02.20 | Stragus | If you want good performance on 3.0, you need texture fetches |
| 00:02.35 | Stragus | And that's a CUDA thing, no idea if it's available on OpenCL |
| 00:02.46 | vasc | oh right |
| 00:02.51 | vasc | well |
| 00:02.57 | vasc | the opencl texture support is kinda crappy |
| 00:03.12 | Stragus | So... there are many good reasons to try to pack everything in a single big chunk of memory |
| 00:03.17 | Notify | 03BRL-CAD Wiki:Bhollister * 9019 /wiki/MGED_CMD_nmg: /* Example(s) */ |
| 00:03.45 | vasc | i think i know what i'll do |
| 00:03.56 | vasc | i'll first compute the size of each solid in the solid list |
| 00:04.08 | vasc | and then i'll do a prefix sum to figure out the offset of each solid |
| 00:04.16 | Stragus | Sounds reasonable |
| 00:04.49 | vasc | the question is where to store the solid type data |
| 00:05.20 | Stragus | In the same big chunk of memory |
| 00:05.26 | vasc | there are 44 solid types |
| 00:05.28 | vasc | so |
| 00:05.37 | Stragus | So? It's just data, doesn't matter what type it is |
| 00:05.40 | vasc | that's like 6 bits |
| 00:05.50 | vasc | well |
| 00:06.02 | vasc | i could stuff it in the solid ids |
| 00:06.14 | vasc | and then i would have like 18 bits |
| 00:06.20 | vasc | oh no |
| 00:06.22 | vasc | 28 bits |
| 00:06.29 | vasc | 26 |
| 00:06.32 | vasc | geez |
| 00:06.32 | Stragus | scratches his head |
| 00:06.34 | Stragus | Right, 26 :p |
| 00:06.57 | vasc | 67 million solids |
| 00:07.02 | vasc | i think that should be enough |
| 00:08.07 | Notify | 03BRL-CAD Wiki:Bhollister * 9020 /wiki/User:Bhollister/DevLogJuly2015: /* Wed, July 15, 2015 */ |
| 00:08.35 | vasc | if we need more i'll just switch to 64 bits |
| 00:08.48 | vasc | and then we get 58 bits |
| 00:08.53 | Stragus | No, just separate the two values then |
| 00:09.05 | Stragus | GPU hardware is better at managing 32 bits values than 64 bits |
| 00:09.15 | vasc | well |
| 00:09.23 | vasc | i'm supposed to use 64-bit doubles and everything |
| 00:09.29 | Stragus | Ouch. |
| 00:09.31 | vasc | really. its a design requirement |
| 00:09.32 | vasc | yep |
| 00:09.34 | vasc | its baaaad |
| 00:09.53 | Stragus | I understand why they need it, but it's not going to be very fast |
| 00:10.03 | vasc | i'll try to make it a compile option |
| 00:10.05 | Stragus | You could support both |
| 00:10.14 | Stragus | Or a runtime option, better |
| 00:10.20 | bhollister | starseeker: updated design docs. need input on newly proposed subcommands before proceeding with their impl. |
| 00:11.03 | vasc | that's gonna be a lot harder |
| 00:11.05 | vasc | although... |
| 00:11.25 | vasc | the thing about opencl is that you don't run binaries |
| 00:11.37 | vasc | you pass source code to the driver and it compiles it on program load |
| 00:11.53 | Stragus | There you go |
| 00:12.20 | vasc | yeah i can just pass a compiler flag to the graphics driver saying which type i want |
| 00:13.06 | Stragus | Yes well, your big-chunk-of-memory data must be of the right type |
| 00:13.28 | Stragus | In my raytracer, I compile the same files many, many times with different #if stuff |
| 00:13.39 | Stragus | To produce a bunch of pipelines optimized for different needs |
| 00:14.17 | vasc | AoS it is |
| 00:14.43 | vasc | SoA is just too much of a problem with all these data types |
| 00:14.50 | Stragus | o.O |
| 00:15.01 | Stragus | Come on, you are going to absolutely destroy performance |
| 00:15.06 | vasc | not really |
| 00:15.13 | Stragus | Yes really |
| 00:15.17 | vasc | its never going to be good |
| 00:15.29 | vasc | because you can have different solid types |
| 00:15.32 | Stragus | It's never going to be good, so it can be much worse and it doesn't matter? :p |
| 00:15.50 | Stragus | That's not a problem if the rays are coherent, they will hit the same solids and be processed simultaneously |
| 00:15.51 | vasc | fine. tell me how to implement SoA with different solid types |
| 00:16.12 | vasc | spheres, ellipsoids, torus, triangle meshes, etc |
| 00:16.13 | Stragus | You can even be clever with ballot() call for the wrap to "vote" on the best execution path |
| 00:16.15 | vasc | all in the same cell |
| 00:16.34 | Stragus | Sure, so you make sure all rays process the same solids coherently, simultaneously |
| 00:16.41 | vasc | ah |
| 00:17.12 | vasc | i can leave that to the next guy |
| 00:17.18 | vasc | :-) |
| 00:17.19 | vasc | well |
| 00:17.24 | Stragus | That next guy will have to rewrite your code to fix this! :) |
| 00:17.29 | vasc | yep |
| 00:17.42 | vasc | well |
| 00:18.08 | vasc | the thing is last time i read about it the coherent grid raytracing isn't faster than the non-coherent one on a gpu |
| 00:18.23 | vasc | so... |
| 00:18.30 | Stragus | The next guy will have to rewrite everything, all the data layout *and* the code, plus wrap coherency considerations and so on |
| 00:18.36 | vasc | nah |
| 00:18.37 | Stragus | Whatever you read, it is totally wrong |
| 00:18.43 | Stragus | wrote a CUDA raytracer |
| 00:18.46 | vasc | as long as its cache coherent its ok |
| 00:19.12 | vasc | if the data is packed decently enough |
| 00:19.16 | vasc | oh now i remembered |
| 00:19.21 | vasc | i'm using spatial subdivision |
| 00:19.28 | vasc | i'll have solids in more than one cell |
| 00:19.30 | vasc | hmmmm |
| 00:20.18 | vasc | so i can only do a coarse sort and hope its coherent |
| 00:20.18 | Stragus | Coherent raytracing is like 10x faster than incoherent rays |
| 00:20.30 | vasc | or i duplicate data and use more mem |
| 00:20.39 | vasc | not on a gpu |
| 00:20.42 | Stragus | Yes, on a GPU |
| 00:20.45 | vasc | at least its what people told me |
| 00:21.03 | Stragus | Seriously, I wrote a CUDA raytracer, it was presented at a Nvidia conference, 1 billion rays per second on decent geometry |
| 00:21.11 | vasc | i know |
| 00:21.20 | Stragus | I have benchmarked all Nvidia hardware a lot |
| 00:21.22 | vasc | i talked with some UT Austin guys in 2009 and they told me that |
| 00:22.06 | vasc | its the SIMT model |
| 00:22.10 | vasc | i guess |
| 00:22.20 | vasc | all the threads will bang the same data anyway |
| 00:22.28 | Stragus | AMD hardware is similar, except a little less flexible than Nvidia's |
| 00:23.01 | Stragus | What you want is all rays to process the same solid simultaneously if they are going to hit it |
| 00:23.11 | vasc | but they already do that more or less |
| 00:23.17 | vasc | or will anyway |
| 00:23.38 | vasc | if the traversal space is similar |
| 00:23.59 | Stragus | Simutaleously? Not one ray processing it first because it reached an intersected cell first, followed by 25 more rays, then some 5 rays, and finally a last ray? |
| 00:24.03 | vasc | if it isn't the coherent grid thing doesn't help a lot either |
| 00:24.05 | Stragus | Your grid can break apart the bundle |
| 00:24.14 | vasc | yeah that's what will happen |
| 00:24.19 | vasc | well |
| 00:24.30 | vasc | later. much later. |
| 00:24.33 | vasc | that's v2.0 stuff. |
| 00:24.43 | Stragus | Okay. But just plan ahead for this |
| 00:25.06 | vasc | its like i said i think a bvh would be better |
| 00:25.18 | vasc | so thinking about coherent grids probably a waste of time |
| 00:25.51 | Stragus | Coherent grids can be faster if the geometry or objects are somehow uniformly distributed... which is not a common case |
| 00:25.54 | vasc | lets just focus on eliminating dynamic memory allocations and gotos, and crap like that for now |
| 00:25.59 | Stragus | :) Okay |
| 00:26.17 | vasc | if its really simple it can be changed later |
| 00:26.33 | vasc | right now this thing is a nightmare to port to opencl |
| 00:26.57 | Stragus | It's certainly fine to start with something quick and dirty, but just plan ahead so the transition to something better will go smoothly |
| 00:27.09 | vasc | yep |
| 00:27.22 | vasc | unfortunately the quick and dirty is still taking a bloody long time |
| 00:27.30 | vasc | because there's a looooot of things to do |
| 00:27.33 | Stragus | :) Yes, I can imagine that |
| 00:28.50 | vasc | the csg boolean thing |
| 00:28.57 | vasc | simplifying that will be interesting... |
| 00:29.01 | vasc | a headache |
| 00:29.15 | vasc | last time i looked at it the code was branching like hell with gotos everywhere |
| 00:30.12 | Stragus | I assume you know it's important to keep the flow as synchroneous as possible on GPU |
| 00:30.24 | Stragus | A lot more computations is better than branches |
| 00:30.34 | vasc | yeah |
| 00:30.42 | vasc | the question is how to do that to rt_boolweave |
| 00:31.30 | Stragus | 's eyes hurt |
| 00:31.40 | Stragus | I sympathize. |
| 00:33.00 | vasc | figuring out a way without dynamic memory allocation would be a start |
| 00:33.26 | vasc | that thing is all branches and dynamic double linked lists |
| 00:33.56 | vasc | and its called on the buffered dynamic linked list of multi-hit intersection for every single cell we intersect |
| 00:35.22 | Stragus | You should clarify with brlcad if you must somehow buffer all hits and return them to CPU code, or if a GPU inlined callback would be sufficient |
| 00:36.07 | Stragus | The first one is messy and slow, and that's a lot of data to constantly copy from GPU to CPU |
| 00:36.28 | vasc | yes |
| 00:36.36 | vasc | well they prefer to keep 100% compat with everything |
| 00:36.51 | vasc | so my guess its that they prefer the first option but its gonna be bad on the long run |
| 00:37.07 | Stragus | They'll need new code to efficiently use a GPU raytracer |
| 00:37.34 | vasc | i thought first i could render on the gpu and cpu and somehow merge results of the whole render |
| 00:37.42 | vasc | but with this multi-hit thing its more tricky |
| 00:38.12 | vasc | like render the gpu accel solids on the gpu and the ones that aren't ported to the gpu would be rendered on the cpu |
| 00:38.28 | vasc | if it was single-hit it would be easy |
| 00:38.29 | Stragus | That doesn't sound good |
| 00:39.16 | vasc | you would just need the depth, object, material, at each pixel |
| 00:39.25 | vasc | on cpu and gpu |
| 00:39.32 | vasc | and then you figured out which was in front |
| 00:39.37 | vasc | for each pixel |
| 00:40.44 | vasc | its not like i can call cpu code inside the gpu |
| 00:40.49 | vasc | unless i pause it all the time |
| 00:40.50 | vasc | hmm |
| 00:41.01 | Stragus | That sounds like much more trouble than just porting all solid types |
| 00:41.14 | vasc | there's like 44 |
| 00:41.15 | vasc | of them |
| 00:41.22 | vasc | i'm gonna port like i dunno 8 |
| 00:41.56 | Stragus | Many of them will be very similar |
| 00:42.22 | vasc | yeah but there's no time before gsoc ends |
| 00:43.16 | Stragus | I would port 8 and leave it to someone else to complete |
| 00:43.23 | Stragus | That cpu-gpu mix is really asking for trouble |
| 00:43.27 | vasc | i also think its the best option yes |
| 00:44.01 | vasc | i'll need to talk about it again with sean |
| 00:44.11 | Stragus | nods |
| 00:46.10 | vasc | thinking about it some more a bvh would simplify some things |
| 00:46.36 | vasc | if i knew the leaves all had the same max number of objects i could still buffer the hits on each cell without using dynamic memory allocation |
| 00:47.24 | Stragus | Why the leaves? Wouldn't it be the maximum count of intersections in the whole scene? |
| 00:48.38 | vasc | i won't claim that i get how the csg stuff works well |
| 00:48.49 | Stragus | I would probably do something like... reserve 8 hits per ray, and each ray can "request" additional chunks of 8 hits when running out of hit space, through some atomics in a giant shared buffer for all hits |
| 00:48.50 | vasc | but it seems to call rt_booleanweave for every cell it intersects |
| 00:49.12 | Stragus | ... giant shared buffer for all rays* |
| 00:49.38 | vasc | but yeah it probably just does that |
| 00:50.24 | vasc | can't you incrementally do the csg? |
| 00:50.37 | vasc | probably need to think this over |
| 00:50.42 | Stragus | You probably know more about CSG than I do :/ |
| 00:51.16 | vasc | i don't know that much |
| 00:51.28 | vasc | i only know its boolean ops in ray tracing |
| 00:51.43 | vasc | i've seen brute force csg ray tracers |
| 00:51.45 | vasc | that's about it |
| 00:51.49 | vasc | but this one ain't brute force |
| 00:54.06 | vasc | at the time i started this sean suggested thinking about other similar algorithms to see if i could do this differently |
| 01:00.16 | Stragus | That sounds like good advice to me |
| 01:00.34 | Stragus | The algorithm's design is probably 30 years old |
| 01:03.43 | Notify | 03BRL-CAD Wiki:Terry.e.wen * 9021 /wiki/User:Terry.e.wen/log: |
| 01:09.05 | *** join/#brlcad vasc__ (~vasc@bl7-122-190.dsl.telepac.pt) |
| 01:21.48 | vasc__ | night |
| 02:59.44 | Notify | 03BRL-CAD:starseeker * 65655 brlcad/trunk/src/libged/nmg_cmface.c: Apply patch #390 from Brad Hollister, removing unused tmp variable. |
| 03:05.39 | Notify | 03BRL-CAD:starseeker * 65656 brlcad/trunk/src/libged/nmg_cmface.c: Apply patch #390 version 2 from Brad Hollister |
| 04:33.06 | *** join/#brlcad infobot (ibot@69-58-76-73.ut.vivintwireless.net) |
| 04:33.06 | *** 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. ;-) |
| 05:08.53 | *** join/#brlcad gurwinder (3b599fa2@gateway/web/freenode/ip.59.89.159.162) |
| 05:16.13 | *** join/#brlcad milinda (~milinda@112.134.13.69) |
| 05:46.36 | *** join/#brlcad milinda (~milinda@124.43.140.87) |
| 06:05.20 | *** join/#brlcad milinda (~milinda@124.43.181.242) |
| 06:47.31 | *** join/#brlcad milinda (~milinda@124.43.92.201) |
| 07:05.15 | *** join/#brlcad milinda (~milinda@112.135.69.88) |
| 07:36.11 | *** join/#brlcad milinda (~milinda@112.134.225.229) |
| 07:37.00 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 08:33.36 | Notify | 03BRL-CAD Wiki:MeShubham99 * 9022 /wiki/User:MeShubham99/GSoc15/log_developmen: /* Week 8 */ |
| 09:15.38 | *** join/#brlcad tess (~tess@122.173.205.133) |
| 10:04.49 | *** join/#brlcad infobot (ibot@69-58-76-73.ut.vivintwireless.net) |
| 10:04.49 | *** 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. ;-) |
| 10:12.52 | *** join/#brlcad gurwinder (75c7660a@gateway/web/freenode/ip.117.199.102.10) |
| 10:31.54 | *** join/#brlcad tess (~tess@122.173.205.133) |
| 11:20.01 | *** join/#brlcad milinda (~milinda@112.134.236.34) |
| 11:28.20 | *** join/#brlcad milinda (~milinda@112.134.236.34) |
| 11:53.40 | *** join/#brlcad Stragus (~alexis@modemcable090.29-19-135.mc.videotron.ca) |
| 12:44.23 | *** join/#brlcad teepee-- (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 12:49.15 | Notify | 03BRL-CAD:ejno * 65657 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: remove unnecessary try block |
| 13:53.55 | *** join/#brlcad milinda (~milinda@124.43.66.153) |
| 14:40.25 | Notify | 03BRL-CAD:brlcad * 65658 brlcad/trunk/TODO: some more thoughts on extending libbu's parallelism functionality |
| 15:00.03 | *** join/#brlcad konrado (~konro@154.70.99.62) |
| 15:03.28 | *** join/#brlcad tess_ (~tess@122.173.205.133) |
| 15:23.56 | Notify | 03BRL-CAD Wiki:MeShubham99 * 9023 /wiki/User:MeShubham99/GSoc15/log_developmen: /* Week 8 */ |
| 15:25.39 | *** join/#brlcad milinda (~milinda@124.43.185.227) |
| 16:23.06 | *** join/#brlcad milinda (~milinda@124.43.185.227) |
| 16:54.58 | *** join/#brlcad sofat (~sofat@202.164.45.204) |
| 17:02.54 | brlcad | Stragus: vasc's problem (regarding solving all problems at once) is that he has a very strict near-term deadline, and has to have made some useful progress by the end .. AND then pass that work on to someone else to continue |
| 17:03.12 | brlcad | so he doesn't really have that luxury |
| 17:11.16 | Stragus | Ah right, I'm still not too familiar with the whole GSoC concept |
| 17:12.46 | Stragus | By the way, I assume you know that if someone is going to port the raytracer to OpenCL, you really need to change the interface and adapt all the code using the raytracer... |
| 17:12.59 | Stragus | It's really not designed for parallel hardware |
| 17:21.33 | brlcad | Stragus: also the opencl implementat that calls a kernel on each solid intersection that you seemed surprised by had absolutely nothing to do with performance (it was only a validation of the calculations being correct for a specific primitive converted, full stop) |
| 17:22.23 | Stragus | Right, makes sense |
| 17:22.58 | milinda | brlcad: Can you please tell me what exactly poly2tri_CDT does ? I mean as a summary ? |
| 17:27.17 | brlcad | "20:35 < Stragus> You should clarify with brlcad if you must somehow buffer all hits and return them to CPU code, or if a GPU inlined callback would be sufficient" <-- well duh, we want both :) |
| 17:27.28 | brlcad | is still reading backlog fwiw, not current discussion |
| 17:28.58 | *** join/#brlcad vasc (~VASC@bl7-122-190.dsl.telepac.pt) |
| 17:30.27 | brlcad | all caught up now |
| 17:31.17 | brlcad | Stragus: yep, definitely know that the interface will need to eventually be adapted -- we'll also need a (slow) compatible interface first though so we can validate the computations |
| 17:31.43 | brlcad | but the goal indeed is to change the method so that analysis applications are also acceleratable and getting updates via callback or in batches or both |
| 17:33.16 | Notify | 03BRL-CAD Wiki:MilindaFernando * 9024 /wiki/User:MilindaFernando/gsoc2015_devlog: /* STEP Viewer Project Development Log */ |
| 17:33.24 | brlcad | the purpose of the single kernel per solid intersection was indeed just to validate correct calculations, and indeed the first conversion was demonstrably different (i.e., wrong) due to precision/tolerance mismatches |
| 17:34.02 | brlcad | milinda: hmmm |
| 17:34.24 | brlcad | looks |
| 17:35.38 | milinda | brlcad: can we please chat I need several things to figure out :) |
| 17:35.53 | Stragus | brlcad: Right. I assume you know that any OpenCL "callback" would have to be built in the same "kernel" (sorry, CUDA speak) as the OpenCL raytracing code |
| 17:36.04 | brlcad | it's doing constrained delaunay triangulation using the poly2tri library |
| 17:36.19 | brlcad | basically, turning the nurbs surface into triangles |
| 17:36.35 | Stragus | In my CUDA raytracer, the user would provide a "callback" and it would build the whole raytracing pipeline with that function inlined directly deep in the code |
| 17:37.13 | brlcad | Stragus: I figured something like that would be necessary for optimal performance |
| 17:37.33 | brlcad | given how the projects are so varied and disjoint, that tight coupling might not be practical |
| 17:37.43 | Stragus | Well, it's not just optimal performance: the other way involves buffering an arbitrary number of hits per ray, and that's really messy |
| 17:37.44 | brlcad | in which case we'll probably pass back bundles of results |
| 17:38.00 | brlcad | which they can process however they like, hopefully coherenty |
| 17:39.03 | milinda | brlcad: Assume we have surface triangles for an geometry. But How can we generate a solid from them ? I mean can you explain me how surface triangles would help to visualize the geometry as a solid in Open GL? |
| 17:39.05 | Stragus | I would suggest designing the OpenCL code so that any code can build custom pipelines with a provided hit-handling callback |
| 17:39.23 | Stragus | Other code could rely on a default pipeline built with hit-handling code that somehow buffers up everything |
| 17:39.41 | milinda | brlcad: Using surface triangles what we get a mesh for the geometry. Is this correct ? |
| 17:39.42 | brlcad | there's more than a dozen external groups that integrate librt for ray intersections for various analytic purposes .. there's no way they will all rework their interface so some will be slow .. some will likely make full accommodations, and others partial |
| 17:39.50 | brlcad | but remember, some of them aren't even in C |
| 17:40.43 | brlcad | some callers are coming through java bindings, some through fortran |
| 17:41.36 | brlcad | milinda: I'm not sure I understand your terminology |
| 17:42.01 | brlcad | milinda: you don't need to generate a solid -- you need triangles you can pass to opengl |
| 17:42.11 | brlcad | getting triangles for each surface does exactly that |
| 17:42.51 | milinda | brlcad: so the final visualized shape would be a triangular mesh of the shape. ? |
| 17:43.08 | brlcad | yes |
| 17:43.36 | milinda | brlcad: are we going to stop with that no solid geometry in the viewer ? |
| 17:44.01 | brlcad | milinda: what does "solid geometry in the viewer" mean to you? |
| 17:44.08 | brlcad | because that terminology is not right |
| 17:44.14 | milinda | brlcad: I mean color shaded shape ? |
| 17:44.52 | brlcad | you color and shade the triangles in opengl |
| 17:45.00 | brlcad | those triangles make a shape |
| 17:46.18 | brlcad | ih8sum3r: I did not, the fibers component failed to compile |
| 17:46.20 | milinda | brlcad: so all the cad programs which does render the geometry as a "visually solid" does it by getting the triangular mesh and color triangles and rt it? |
| 17:46.57 | brlcad | ih8sum3r: looks like relatively simple portability errors, but "npm install fibers" worked |
| 17:47.02 | brlcad | it installed 1.0.6 |
| 17:47.34 | brlcad | milinda: they get a trinagular mesh, color the triangles, and send it to opengl |
| 17:47.53 | brlcad | milinda: do you have an install of brl-cad handy? |
| 17:47.56 | ih8sum3r | brlcad: Same error on my side. Okay I will try with 1.0.6 version. |
| 17:48.11 | vasc | howdy |
| 17:49.38 | brlcad | hi vasc |
| 17:49.43 | brlcad | read your nice long convo yesterday |
| 17:49.51 | brlcad | good thoughts all around |
| 17:50.12 | vasc | i still need to do a bunch of things before i start working on the boolean weaving though |
| 17:50.25 | brlcad | the main limiting factor here is time and wanting something incrementally useful *before* gsoc is over (it's already crazy risky enough) |
| 17:50.34 | milinda | brlcad: No Should I install it ? |
| 17:51.18 | brlcad | milinda: if you going to be calling into brl-cad libs, aren't having those libs installed required? :) |
| 17:52.20 | milinda | brlcad: yes I need to install them :) |
| 17:53.28 | milinda | brlcad: So as the next step what should I do is a write a function which takes a ON_Brep structure and browse all the surface triangles ? Correct ? |
| 17:54.04 | milinda | brlcad: then we can get a tringluar mesh at the viewer. :) |
| 17:54.42 | brlcad | well once you do that, you can find a simple 3dm model online (e.g., from grabcad.com), convert it with "3dm-g", then open that .g file with our "mged" application, and run commands that let you visualize ("tops" will tell you names to use, and "draw -m1 somename" will display that nurbs as shaded triangles) |
| 17:55.07 | brlcad | milinda: an ON_Brep intrinsically does not have surface triangles |
| 17:55.10 | brlcad | they have to be calculated |
| 17:55.46 | brlcad | that is exactly what we do (in rt_brep_plot_poly and the CDT library calls) |
| 17:56.41 | milinda | brlcad: you mean I should Install the libraries and call them instead of writing new code to do that. ? |
| 17:57.50 | brlcad | milinda: I think it took one of our devs about 4-6 months to calculate the triangles in a useful manner |
| 17:58.31 | brlcad | it's easily a gsoc project all of it's own just to do that... |
| 17:58.53 | brlcad | so yeah, that's why in your original proposal, it was suggested that you leverage our work |
| 17:59.17 | brlcad | now whether you call a library or extract the code of signficance doesn't really matter (so long as attribution and legalities are correct) |
| 18:00.30 | vasc | so you just sample a bunch of points on the surface and triangulate that? |
| 18:02.46 | ih8sum3r | brlcad: I guess fibers are not installed properly, I'm getting this error : Error: Cannot find module 'fibers' |
| 18:14.19 | *** join/#brlcad milinda (~milinda@124.43.95.17) |
| 18:14.24 | brlcad | vasc: for triangulation, that's all you can do |
| 18:14.43 | brlcad | there are other modes of visualization, like just rendering the surface edge splines |
| 18:15.18 | brlcad | but the surface itself doesn't have anything intrinsic that can be sent to opengl, you have to evaluate surface polylines, points, triangles, etc |
| 18:17.34 | brlcad | an older slower method involved converting the nurbs surfaces into a set of bezier patches, and triangulating those patches for visualization |
| 18:17.48 | brlcad | some CAD systems still use that indirect method |
| 18:18.59 | brlcad | triangulating bezier patches is also still just sampling points on the surface so you can make a mesh, it's just a much simpler evaluation than directly evaluating the complex nurbs surface (high high order equations) |
| 18:19.19 | vasc | i see. it seemed kinda of brute force so i thought that someone had come up with something better. |
| 18:23.15 | brlcad | polylines is arguably better, but opengl doesn't have support for shaded rendering of polyline strips |
| 18:23.36 | brlcad | GLU has support for rendering NURBS, but it basically does the old bezier patch method |
| 18:24.26 | brlcad | you can do adaptive sampling of the NURBS, and that's about as good as it gets for sending something to opengl |
| 18:25.04 | vasc | i'm gonna have a masters student working on NURBS next year so i was kind of interest |
| 18:25.05 | vasc | ed |
| 18:29.32 | vasc | i keep hearing that the latest opengl has tesselation support so i thought there would be some better way of doing it or something |
| 18:38.12 | starseeker | growls at sourceforge... |
| 18:38.23 | vasc | switch to github then |
| 18:38.54 | starseeker | brlcad-as-git-checkout is.... rather large. we have a lot of history |
| 18:39.21 | vasc | more than the linux kernel? |
| 18:39.26 | vasc | oh right |
| 18:39.28 | vasc | 1970s |
| 18:39.41 | vasc | how far back does the repo go anyway? |
| 18:39.46 | starseeker | 1983 |
| 18:40.39 | starseeker | I've done a git conversion of our svn repo (even have the process quasi-automated) and it clocks in at 1.6 gigs |
| 18:40.40 | vasc | even old than gcc then |
| 18:41.09 | vasc | oh i see |
| 18:41.18 | vasc | github says they want repos to be below 1GB |
| 18:41.54 | starseeker | http://blog.openhub.net/2012/10/oldies-but-goodies-seven-projects-still-rocking-open-source/ |
| 18:42.30 | Stragus | vasc, OpenGL has "tesselation shaders", and nobody uses them, just like geometry shaders |
| 18:42.45 | ``Erik | http://brlcad.org/brlcad.git is daily conversion/mirror |
| 18:43.01 | Stragus | It's too slow and limited. Compute shaders replace all of this mess |
| 18:43.41 | starseeker | we could probably do some tricks like one project per src/other folder to spread the pain out |
| 18:44.45 | starseeker | hasn't tried building our history without src/other and misc/tools, but probably smaller |
| 18:45.19 | starseeker | is now curious... |
| 18:45.58 | vasc | oh right the dependencies |
| 18:46.27 | vasc | those are probably pretty big since have tcl/tk in there |
| 18:46.46 | starseeker | and a subset of boost, at some point in the history |
| 18:50.33 | starseeker | tries a "quick and dirty" approach... to do this right would require some care... |
| 18:54.31 | vasc | https://rtyley.github.io/bfg-repo-cleaner/ |
| 18:55.48 | vasc | maybe that will help |
| 18:56.26 | starseeker | vasc: the problem is stripping out large commits from older history would result in broken checkouts for those revisions |
| 18:56.40 | starseeker | it's occasionally necessary to test older revisions |
| 18:57.09 | starseeker | that would be good for checked in garbage, but when the large bits are actually *needed* we're worse off... |
| 18:58.37 | starseeker | might conceivably be acceptable for things that never worked right to begin with, but even that's a bit dicy... |
| 18:59.22 | vasc | so you need this one http://git-scm.com/docs/git-filter-branch |
| 19:00.57 | starseeker | probably, plus a *lot* of detailed history study to see what is in, what's out and what things look like for various options. Probably a lot of testing as well |
| 19:01.12 | vasc | another choice i guess is to break the repo at some point in time and archive that keeping on the repo only a shortened history |
| 19:01.25 | starseeker | don't let brlcad hear you suggest that ;-) |
| 19:02.13 | vasc | self-hosting then :-) |
| 19:02.19 | starseeker | heh |
| 19:02.20 | vasc | bbl |
| 19:03.11 | *** join/#brlcad milinda (~milinda@124.43.75.66) |
| 19:05.59 | starseeker | bah - filtering out other only saved 150 megs |
| 19:06.07 | starseeker | wonders if he did something wrong... |
| 19:07.23 | starseeker | looks right... |
| 19:07.26 | starseeker | huh |
| 19:08.18 | starseeker | wonders if there are some commit size analysis tools available somewhere... |
| 19:08.48 | starseeker | and... of course https://code.google.com/p/gitinspector/ |
| 19:11.51 | starseeker | ah http://serverfault.com/questions/36784/search-for-large-checkins-in-a-subversion-repository |
| 19:15.54 | brlcad | yeah, I'm not at all keen on stripping or contorting the history for the sake of the tool/repo/size/whatever |
| 19:18.03 | starseeker | suspects BRL-CAD on github is probably a practical no-go |
| 19:18.43 | brlcad | I'm certainly not opposed, but I wouldn't switch on a whim |
| 19:19.14 | starseeker | we'd basically have to explain the situation to them and get an OK, and even then they may not be too keen on 2 gig forks... |
| 19:20.45 | brlcad | I would, but I'd doubt size would be a problem |
| 19:21.00 | brlcad | it's real history and there's no large files clogging it up |
| 19:21.03 | brlcad | just a ton of history |
| 19:21.29 | starseeker | couple of our hacking book images would be a problem |
| 19:22.04 | brlcad | large ==> >100MB |
| 19:22.34 | brlcad | I don't think we have much at >10MB |
| 19:22.39 | starseeker | ah, OK |
| 19:22.50 | starseeker | thought a couple of the high quality renders were bigger |
| 19:23.04 | starseeker | just my not-so-hot internet connection |
| 19:23.54 | *** join/#brlcad milinda (~milinda@124.43.202.141) |
| 19:23.55 | brlcad | they got checked in? |
| 19:24.17 | starseeker | yeah - we added the hacking book to the doc build (or at least I thought we did) |
| 19:25.47 | brlcad | I know the book was added, but I didn't think the images were that big |
| 19:25.52 | starseeker | they aren't |
| 19:25.58 | brlcad | the biggest was probably teapot at 4k x 4k but in png format |
| 19:26.20 | starseeker | biggest is 12M |
| 19:26.27 | starseeker | sphflace2_cc |
| 19:26.47 | starseeker | teh M1A1 is second at 8, rest are below 4 |
| 19:27.06 | starseeker | s/teh/the |
| 19:29.41 | brlcad | okay, makes sense |
| 19:30.06 | starseeker | ah, cool - that svn size-of-revision script looks like it worked |
| 19:30.16 | brlcad | that sounds entirely reasonable to me |
| 19:35.02 | starseeker | interesting - if I'm reading this right, even the largest merges are around 90 megs |
| 19:35.09 | brlcad | looks like our biggest commit is r31506 |
| 19:35.16 | brlcad | looks like a commit that added ogre |
| 19:35.30 | Stragus | Ogre? The 3D engine? |
| 19:35.37 | starseeker | is that bigger than r23577? |
| 19:35.47 | brlcad | Stragus: yep |
| 19:36.02 | Stragus | That's a weird dependency to have |
| 19:36.21 | starseeker | Stragus: we're a CAD system - why's a 3d engine a weird dep? |
| 19:36.41 | brlcad | Stragus: experimental GUI work looking at using it for the CAD visuals |
| 19:37.21 | Stragus | Because a CAD system doesn't need a gaming-oriented 3D engine |
| 19:38.23 | starseeker | Stragus: fwiw, we're also checking out OpenSceneGraph |
| 19:38.31 | Stragus | once also wrote an OpenGL-rendered GUI, but creating the widgets became tiresome... http://www.rayforce.net/glui000.png |
| 19:38.51 | brlcad | it's not really any more gaming-oriented than openscenegraph, OSG, VTK, and a handful of others |
| 19:39.46 | starseeker | Stragus: I've had half an eye on this for a long while hoping it would reach a usable point: https://github.com/zhanggyb/BlendInt |
| 19:41.07 | Stragus | I haven't heard of that one |
| 19:41.08 | brlcad | an engine is desirable for some pretty basic aspects like asset management and scene graph management |
| 19:41.37 | brlcad | writing the code to do that well is really a distraction to our goals, especially when they do it more than adequate for our needs |
| 19:41.52 | Stragus | My GL gui was quite usable, just still missing a bunch of widgets (that screenshot is also old) |
| 19:42.20 | *** join/#brlcad milinda (~milinda@124.43.188.93) |
| 19:42.31 | starseeker | Stragus: we've been looking at using Qt-in-GL, sorta like stellarium |
| 19:44.01 | starseeker | there are actually some reasonably impressive demos with qml, but IIRC the primary widgets remain something of a challenge |
| 19:44.02 | brlcad | for GUI, I have many in depth strong opinions and am quite picky about usability characteristics -- at least for our 3rd generation interface |
| 19:44.38 | starseeker | that's why starseeker considers qged 2.5gen ;-) |
| 19:45.36 | *** join/#brlcad gurwinder (3b5b7739@gateway/web/freenode/ip.59.91.119.57) |
| 19:45.44 | brlcad | why not embrace it? |
| 19:46.11 | brlcad | what's the .5 missing? |
| 19:46.41 | starseeker | satisfying the in depth strong opinions and usability characteristics ;-) |
| 19:47.02 | starseeker | would be content with cleaner-archer-not-needing-Tk as a start |
| 19:47.28 | Stragus | has this habit of always writing everything from scratch, no dependencies |
| 19:48.14 | brlcad | Stragus: yeah, I get really pissed off at interfaces like that from a usability perspective... I admire the work, but the usability is usually just .. terrible |
| 19:48.22 | Notify | 03BRL-CAD Wiki:59.91.119.57 * 9025 /wiki/User:Gurwinder_Singh/GSoc15/log_developmen: |
| 19:48.27 | Stragus | Writing an OpenGL engine isn't that much work anyway, I wrote that some time ago: http://www.rayforce.net/newproject024.png |
| 19:48.28 | brlcad | love the appearance of custom, though, that alone can be a saving grace |
| 19:48.32 | starseeker | figures a real 3rd gen interface will be a fairly significant depature from the mged/archer paradigms |
| 19:48.56 | brlcad | doesn't |
| 19:49.28 | brlcad | significant in the sense that the new one should be explorable, yes |
| 19:49.44 | brlcad | pretty and easier to learn, yes |
| 19:50.16 | Stragus | Eheh brlcad, you want widgets that look and behave like the standard, right. |
| 19:50.20 | brlcad | functionality, though, no change really |
| 19:50.28 | brlcad | Stragus: nope |
| 19:50.54 | brlcad | behavior to a limited extent (key bindings, some presentation patterns) |
| 19:52.01 | brlcad | appearance, definitely not |
| 19:52.44 | Stragus | Okay, so what bothers you about the usability of different-looking GUIs? |
| 19:52.46 | starseeker | brlcad: well, for example, the original ogre/qt work was focused on Qt widgets in the 3d scene - that's something I didn't envision for qged. I'd be content to use osgQt to get an OpenSceneGraph window that gets passed to libdm (after upgrading libdm's API...) |
| 19:53.09 | brlcad | cursed with having studied interface design measurement and usability theory -- there are some fundamental issues regarding design patterns, familiarity, efficiency, discoverability |
| 19:54.09 | Stragus | That depends entirely on how the programmer writes his code using the GUI, not the GUI itself |
| 19:54.22 | brlcad | starseeker: now you're talking about "how", not "what" .. I frankly don't care much how as long as it doesn't get in the way of maintainability and longer-term development |
| 19:55.08 | starseeker | fair enough |
| 19:55.15 | brlcad | the issue is what usability patterns are made available, what steps the user takes to do some action |
| 19:55.39 | brlcad | it's very user-centric, which becomes the dev's problem |
| 19:55.48 | starseeker | so from that standpoint, whether Qt elements are available in the 3D scene or not is a detail? |
| 19:56.26 | brlcad | you don't just pop up a text field where a value needs to be input, which I could code up manually or delegate to a widget library and leave to whatever limitations/complexity that implies |
| 19:58.00 | brlcad | if the user is given a text field, it better behave to platform expectations -- which means they get navigation key-bindings, cursor controls, probably even basic field checking (e.g., spell checking, bounds checks, etc) |
| 19:58.37 | brlcad | Stragus: that's a good case point example -- did you input a text input field? |
| 19:59.16 | Stragus | Yes, with support for tab, alt+tab, arrow keys, shift+arrow, ctrl+arrow |
| 19:59.51 | brlcad | ctrl-a, ctrl-e, ctrl-w, ... |
| 20:00.21 | brlcad | those little nitpick issues seem inconsequential, but play a MAJOR role in long term usability and adoption |
| 20:00.28 | Stragus | Only the first one of these, but yes, you demand standard behavior |
| 20:00.33 | brlcad | did you spell check the words on the fly |
| 20:00.35 | Stragus | Oh I agree |
| 20:00.39 | Stragus | No :p |
| 20:00.47 | brlcad | that's just the tip |
| 20:01.30 | brlcad | that's we're leveraging something like Qt because valuable because they either have invested the effort already or provide all the necessary hooks |
| 20:01.31 | Stragus | I pretty much wrote that GUI system for my own needs as learning an existing GUI seemed... boring |
| 20:01.39 | Stragus | Indeed |
| 20:01.40 | brlcad | nods |
| 20:02.00 | brlcad | it can be boring, but that's where the fun is in stylistic presentation |
| 20:02.12 | brlcad | there is some amazing research work in GUI stylization |
| 20:03.09 | Stragus | finds it more fun to optimize GPU texture caching of all GUI "images" with clever area invalidation, minimized scissoring, batching and other tricks |
| 20:03.17 | Stragus | But yes, I certainlt understand your points |
| 20:03.20 | Stragus | certainly* |
| 20:05.51 | brlcad | starseeker: probably the biggest piece I see required for gen3 is a fully pervasive on-demand command functionality |
| 20:05.54 | brlcad | (not the command console, that's a separate issue/feature) |
| 20:09.43 | *** join/#brlcad Izakey (~Isaac@41.205.22.26) |
| 20:10.21 | brlcad | Izakey: still have that link handy? maybe starseeker can help... |
| 20:11.27 | Izakey | brlcad, I tried rectifying the libpng today and it blew away my entire GUI |
| 20:11.56 | brlcad | ouch! |
| 20:12.02 | Izakey | I'm accessing this channel using a mobile device. Let me find the link however |
| 20:12.11 | brlcad | sounds like .. you did something wrong :/ |
| 20:14.05 | starseeker | O.o |
| 20:15.42 | Izakey | Yeah, libpng was at 12. I installed,deleted and reinstalled libpng16.so.16 or so and my computer just powered itself off |
| 20:16.13 | Izakey | starseeker, this is the link https://paste.kde.org/pab6nw3ai |
| 20:17.10 | Izakey | A man without Xserver needs all the help he can get ;) |
| 20:17.15 | Stragus | libpng is not binary compatible between major versions |
| 20:17.46 | Stragus | Reinstall libpng 1.2, or rebuild everything that depends on it |
| 20:19.17 | Izakey | Thanks Stragus. |
| 20:20.40 | Stragus | isn't fond of that whole Unix philosophy of software linking tons of libraries instead of including the dependencies at build time |
| 20:20.55 | brlcad | starseeker: if you want some GUI homework to look into, try playing with Kupfer! or Synapse on Linux -- they incorporate some relevant usability concepts based on research |
| 20:21.26 | brlcad | somewhat similar to quicksilver on mac os x |
| 20:21.51 | brlcad | or even spotlight, but that interface is only half-there |
| 20:22.41 | brlcad | ah, Gnome Do might be similar too |
| 20:22.51 | brlcad | but i've just found that one now |
| 20:22.52 | Izakey | will not advise playing with GUI after today's experience |
| 20:23.09 | brlcad | "GNOME Do is inspired by Quicksilver" ... so apparently yes |
| 20:23.29 | brlcad | Izakey: you should be able to restore your GUI just by restoring libpng, no? |
| 20:23.40 | brlcad | what'd you do to it? |
| 20:23.45 | Stragus | Izakey, how did you end up replacing the installed libpng? |
| 20:24.05 | Stragus | Gentoo builds libpng12.so, libpng13.so, libpng14.so, etc. to avoid that kind of problem |
| 20:24.07 | Izakey | I used rpm to install the .rpm file |
| 20:24.36 | brlcad | just installing wouldn't have easily broken something unless an RPM overwrote a symlink |
| 20:24.54 | brlcad | would have had to overwrite/delete a symlink or delete the old lib |
| 20:24.57 | Izakey | My entire Fedora is bash - from login to what have you |
| 20:25.14 | brlcad | Izakey: also, needed the entire build log, including the cmake output |
| 20:26.23 | brlcad | prefers linux without an X server :) |
| 20:26.34 | Izakey | The cmake build log from yesterday ? brlcad |
| 20:26.47 | brlcad | I never got to see it because the url was blocked |
| 20:26.55 | brlcad | I can probably get to it now |
| 20:27.55 | Izakey | thinks Linux without Xserver can really suck |
| 20:28.39 | Stragus | spent 2 days in text mode when his GPU fried from too much CUDA, a month ago |
| 20:28.54 | Stragus | You get used to it, eh |
| 20:31.20 | Izakey | fetches yesterday's build log |
| 20:34.58 | starseeker | Izakey: did you try -DBRLCAD_ENABLE_ALL=ON ? |
| 20:35.52 | Izakey | Yes starseeker ? |
| 20:36.00 | starseeker | and you still got that error? |
| 20:36.23 | Izakey | Yes starseeker |
| 20:36.38 | starseeker | somethings wrong then - it's pulling the wrong libpng |
| 20:36.43 | starseeker | it should be using a locally built copy |
| 20:37.01 | starseeker | ditto for zlib |
| 20:37.03 | ``Erik | heh, console 4evah! |
| 20:37.18 | starseeker | yeah, need full log for this one |
| 20:38.56 | Stragus | I frequently kill X and switch to raw console when I want precise benchmarks |
| 20:43.27 | ``Erik | http://elfga.com/~erik/tmp/ss20150716164155.png is what my mac lappie usually looks like (sometimes I fullscreen terminal just to be cool, but usually it's just maximized) :D |
| 20:45.19 | Izakey | console 4evah ! ``Erik |
| 20:46.02 | Stragus | I can relate: http://www.rayforce.net/desktop000.png |
| 20:48.19 | ``Erik | still using bx? |
| 20:48.56 | Stragus | Yup |
| 20:50.39 | Izakey | brlcad, I've given you access to the Google Doc. |
| 20:50.44 | ``Erik | I got sick of fighting the logging facility in bx, irssi did things 'mostly' right out of the box, so I was willing to spend the extra resources on it *shrug* :) |
| 20:56.03 | *** join/#brlcad vasc (~vasc@bl7-122-190.dsl.telepac.pt) |
| 20:56.22 | vasc | man sf.net is still down |
| 20:59.03 | *** join/#brlcad Yash (3b5f267d@gateway/web/cgi-irc/kiwiirc.com/ip.59.95.38.125) |
| 21:06.16 | *** join/#brlcad konrado (~konro@41.205.22.37) |
| 21:06.25 | Yash | hi |
| 21:09.04 | *** join/#brlcad Yash (3b5f267d@gateway/web/cgi-irc/kiwiirc.com/ip.59.95.38.125) |
| 21:09.57 | Notify | 03BRL-CAD Wiki:Konrado DJ * 9026 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 16 JULY 2015 */ |
| 21:10.56 | Notify | 03BRL-CAD Wiki:Konrado DJ * 9027 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 16 JULY 2015 */ |
| 21:25.06 | vasc | hello Yash |
| 21:25.58 | Yash | hi |
| 22:20.41 | *** join/#brlcad vasc (~vasc@bl7-122-190.dsl.telepac.pt) |
| 22:27.47 | Notify | 03BRL-CAD Wiki:Bhollister * 9028 /wiki/MGED_CMD_nmg: |
| 22:37.37 | Notify | 03BRL-CAD Wiki:Bhollister * 9029 /wiki/MGED_CMD_nmg: /* Example(s) */ |
| 22:39.16 | Notify | 03BRL-CAD Wiki:Bhollister * 9030 /wiki/MGED_CMD_nmg: /* Proposed subcommands */ |
| 22:42.11 | Notify | 03BRL-CAD Wiki:Bhollister * 9031 /wiki/MGED_CMD_nmg: /* Example(s) */ |
| 22:42.47 | *** join/#brlcad ih8sum3r (~ih8sum3r@122.173.205.133) |
| 23:00.15 | Notify | 03BRL-CAD Wiki:202.164.45.204 * 9032 /wiki/User:Hiteshsofat/GSoc15/log_developmen: |
| 23:05.06 | Notify | 03BRL-CAD Wiki:Bhollister * 9033 /wiki/User:Bhollister/DevLogJuly2015: /* Thurs, July 16, 2015 */ |
| 23:06.20 | Notify | 03BRL-CAD Wiki:Bhollister * 9034 /wiki/User:Bhollister/DevLogJuly2015: /* Mon, July 20, 2015: Start of Week 9 (of 14) */ |
