On Mar 31, 2013, at 12:26 AM, Csaba Nagy wrote: > I had a look at the GCI 2012 completed tasks, pipe was not in the list - > so I assume it was not done for this primitive. I'll provide pipe > volume/surface/centroid + length functions.
Yeah, several of our primitives were outside the scope of a GCI task, which was roughly supposed to take about 2 hours. Pipe is going to be tricky to get right. > Already started working on it, and there are a few things I noted: Awesome. > 1) most pipe tasks need to iterate through the pipe segments - the loop > code is repeating and should be abstracted out; Whenever you find a way to refactor out repetition, go for it. That'd make for a good patch/commit all by itself. The smaller and modular the patch, the easier to review and apply so we can get you set up. Relevant, duplication reduction commentary: http://brlcad.org/wiki/Code_Cleanup > In Java I would solved that via an iterator, my limited C experience > misses this aspect. Understandably so. The main difference isn't so much Java as it is what class/struct/data is underpinning. For sections of our code where we use C++ containers, we do use standard iterators like one might expect. For our basic utility library (libbu, see bu.h), we define abstracted iterators for many/most of the containers (mostly via macros like you suggested). For our ray tracing library and other higher-level application code, they usually are far too complex and we use functional-style programming callback functions. > I looked up "ansi C iterator" and got this nice > link: > > http://pine.cs.yale.edu/pinewiki/C/Iterators One of the characteristics of being such a large codebase, we readily implement all three methods listed there. ;) Tradeoffs abound. > [snip] > > My personal preference would be the one with iterator object, but if > brl-cad has some other standard way to handle it, please point me to > it... There's no recursion or complexity, so your personal preference would work just fine here. I'd lean towards the iterator function myself, but any of the three really sound reasonable. As for our "standard" ways for handling it. No such thing. We use macros and iterator functions in literally thousands of places, but it depends on the data and container involved. You'll see the libbu iterator macros (see bu.h) are used all throughout pipe.c, a couple easy-to-see examples: BU_LIST_WHILE() in rt_pipe_free() and rt_pipe_ifree() BU_LIST_FOR() in rt_pipe_export5() > The iterator object approach could solve that, if that object would be > shared between these functions, and would cache the intermediate > calculations for the pipe segments. The iterator object needs then to be > passed to the info calculation functions, and would calculate the pipe > segments only on the first iteration, then just serve them on further > iterations. This iterator will then be created by the "analyze" function > and given to each of the sub-functions which calculate > volume/surface/centroid/length/etc. I'd only caution about optimizing information for reuse without first implementing it directly and running a performance profile. Those analysis functions are probably going to get calculated in relatively few cpu cycles. That means crazy fast. The difference between calculating a pipe's volume+surfacearea+centroid in 0.001ms vs 0.00001ms is moot until we have a million pipes to calculate all at once. That's not likely. If it makes coding easier and the cache doesn't pass an encapsulation boundary (app to lib or lib to app), then it's an implementation detail up to the implementer. ;) > 3) analyze has a switch on idb_type, and calls multiple individual > functions for each primitive type - not very good for abstracting the > analyze capabilities; Last I counted, there are a couple down places where we have a switch over idb_type. Every one of those is a case for refactoring and can be considered a FIXME or TODO to push it up into librt. Usually the switch was created because the functab was lacking and something was needed quick. > One more thing: among the GCI tasks I've seen some "Create Solid Model > and Diagram" ones for visualizing the parameters of primitive types. I > wonder what if those parameters would be implemented directly in the > primitive code as functions which return vertexes/curves representing > those params, matching the primitive object they are called on ? Then it > would be trivial to also draw those together with the object for > visualization purposes. They could additionally be used for > programmatically positioning other objects in relation to the reference > primitive. That was actually part of the underlying two-fold intent of those tasks. One purpose was to have an image we could shove into documentation immediately. The other was to have someone begin thinking through what those implicit and explicit parameters might be, how to display them effectively, and what sorts of issues might arise (as several did). Basically, do it by hand before doing it programmatic. > This presumes BRL-CAD supports non-solid vertex + curve object types, > used as helpers in constructing the solid objects - is that so ? Those > kind of helper objects are also useful e.g. in animation as trajectory, > or placing repeated objects on a path, etc. We have them in the wireframe. We also have them in our 2D sketch objects. However, I think 3D annotations would be most apropos, where you can easily define common stylized constructs like a dashed leader line with an arrowhead on one end and a sphere on the other, e.g., o - - - - - > I can fake it in wireframe with vector lists or manually draw something as a sketch, but I'd rather describe it implicitly (dashed leader line from A to B), and have it be displayed in a context-dependent manner (e.g., in 3D during ray-tracing). That's something that was started last year and has some text written up in the TODO file, but was shelved a while back due to some other priorities that came up. Good thoughts, great questions. Thanks Csaba! Cheers! Sean ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
