>
> 2. Vector output from
> Raytracing<http://brlcad.org/wiki/Vector_output_from_raytracing>
>>
>>
>> I would be very interested in this one as well I would like to try to
> test out the surface-surface intersections in 3D which then can be
> projected to give out an vector image(.svg) as output.
>
>
> If you wanted to take that task on, I'd suggest *just* proposing the
> implementation of surface-surface intersections. That's a hot-topic
> want-it-badly development topic (even more so than vector output) because
> it impacts so many things. BUT, that single function by itself would very
> likely task the entire timeframe of GSoC and was attempted once before
> unsuccessfully. Read up on NURBS surfaces if you want a taste of the
> complexity involved.
>
Thanks for the advice. Perhaps I was being unrealistic about the outcome.
Heeding your advice, I have started reading up on the topic, and would try
to formulate a decent proposal with 'one' topic. I believe this would be a
nice mix of learning and coding and hence my first choice.
>
> 3. Density Function <http://brlcad.org/wiki/Density_functions>
>>
>>
> Furthermore, do you think it is possible (and needed) to sample rays, to
> get a set of these density distributions, and then render them as heat map
> (red for sense-blue for less dense) superposed on the object in 3D. Also we
> can then define a control, where the user can run through the object (in
> the same way we run through a 3d volume of CT-Scan slice by slice). And
> each slice (or cross-section) would display a combination of the densities
> along all the rays normal to that slice at that particular depth. This
> might be useful in structural analysis.
>
> From your description of the problem, I believe this is a relatively low
> hanging fruit, and I would like to complete this task in the first part of
> my term, in case I am chosen.
>
>
> It's not that simple at all. We already have a "heat map" tool that does
> something like you suggest visualizing object densities. The problem (and
> point of this task) is to return parametric density *function* for a given
> 3D line. It's a function of one variable f(t) that returns the density for
> a given position t along the ray segment. With that function, I can
> calculate the aggregate average density, inspect the initial density, find
> high/low points, etc. The hard parts are actually coming up with a way to
> define 3D parametric density f(x,y,z) for arbitrary shapes and then
> calculating f(t) per ray: f(x, y, z) -> f(t)
>
> Just coming up with a working user interface for describing a parametric
> density function will probably consume most of GSoC, so it would not be
> advisable to mix this topic with any other proposed topic. You're
> certainly welcome and encouraged to submit two project applications, though.
>
> I apologize for underestimating the problem. I believe its better to
segregate the proposals. I will look into the existing function, and write
up a draft proposal to over by the end of this week.
That goes for everyone. Two detailed applications will usually increase
> your chances of being selected greatly Add in a working patch and a good
> dose of healthy mailing list or IRC communication, and it's often a done
> deal.
>
> That's great then. I will try to write two compelling proposals each of
which should possibly be completed within time.
> Honestly, I am equally excited by all three and would like to start doing
> the easiest and then move on to either, in case time permits.
>
>
> GSoC allows for the scope of projects to be adjusted, but it's far easier
> to expand scope than to decrease it. I've yet to meet a student for any
> org that actually completed everything they set out to do in their initial
> application. Remember that communication, testing code, usability
> discussions, and status updates are all required too (and can take anywhere
> from 25-50% of your time depending on the project in question).
>
> One more piece of advice, would it hurt my application if not substantial
> pieces of my previous code are not open-source. ( I cant release them due
> to several research commitments).
>
>
> It wouldn't hurt it. It would make your application invalid. All code
> developed for GSoC must be open source, that's the same for all orgs and
> one of the core tenants of GSoC. For BRL-CAD in particular, your work
> becomes committed to our public source code repository and forever becomes
> part of BRL-CAD. See http://brlcad.org/wiki/Summer_of_Code/Acceptancefor
> more participation requirements.
>
Possibly, I did not word my question correctly. I understand that all the
contribution *during/for* GSoC is open source. My query was about the
importance of 'previous' code being open source to prove competence.
Thanks a lot Sean for your help.
Regards
Animesh
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
