Hello Vasco Sir,
Thanks a lot for your consideration.
So let me update the list of primitives which I am planning to port:
- DSP
- HLF
- HYP
- SUPERELL
- EBM
- EXTRUDE
- REVOLVE
- HF (I am not very sure)
- SUBMODEL (a bit difficult one)
As you described above, I feel these many primitives would be enough to
keep me engaged for the 3 months.
Do let me know your suggestions.
Also, I am active on irc.freenode with handle "shailesh". Please tell me
when you are free.
Regards
Shailesh
Shailesh Tripathi
B.Tech. Part-IV
Electronics Engineering
IIT-BHU (Varanasi)
On Sat, Apr 1, 2017 at 8:27 AM, Vasco Alexandre da Silva Costa <
vasco.co...@gmail.com> wrote:
> Hello,
> Like I said before, on our prior conversation, delete your first two
> pages. You don't need a title page or a contents page on a short proposal
> document. The written content seems a bit verbose and redundant but it's
> mostly ok.
>
> Don't use Comic Sans (it's an offense to font design!). Arial is already
> bad enough. Use justified mode as it makes following text on long
> paragraphs easier.
>
> RHC and RPC are already implemented, like you noted, and I've desk checked
> their patches and they're ok. I just haven't found the time to test and
> commit them yet. So you can remove them from your document.
>
> Some of the primitives are going to be harder to implement than considered
> in your plan. I'll give you an example. The HALF (Half Space) primitive has
> basically infinite volume so it doesn't play nicely with the BVH (Bounding
> Volume Hierarchy) object partitioning acceleration structure we currently
> have. For this reason some 3D solid modeling tools won't even allow that
> primitive.
>
> Some of the primitives are composite primitives (e.g. SUBMODEL) and this
> means their implementation will be more subtle.
>
> EXTRUDE and REVOLVE aren't included in your list of primitives to
> implement and those are typically fairly common solid modeling operations.
>
> Other primitives, like the METABALL, are experimental, possibly buggy, and
> I don't know if anyone even uses them. You would have to ask someone who's
> been along here longer to know it for sure.
>
> DSP (Displacement Map), HF (Heightfield), and EBM (Extruded Bitmap) can
> probably be merged together for the most part as their code is relatively
> similar. The problem is with backwards compatibility with existing code.
> AFAIK DSP and HF are already using the same algorithm on the default code
> path.
>
> VOL (3D Volume) is not similar to a quadric at all. If anything it's
> similar to the HF (Heightfield) code because it also uses grid traversal.
>
> Regards,
>
>
> On Sat, Apr 1, 2017 at 1:13 AM, Shailesh Tripathi <
> shailesh.tripathi.ec...@itbhu.ac.in> wrote:
>
>> My proposal: https://docs.google.com/document/d/1cmIVxU22cFENhS4OvE2JCpIJ
>> y_g4ZRYsNIPyklTC1i8/edit?usp=sharing
>>
>>
>> Shailesh Tripathi
>> B.Tech. Part-IV
>> Electronics Engineering
>> IIT-BHU (Varanasi)
>>
>> On Sat, Apr 1, 2017 at 5:33 AM, Shailesh Tripathi <
>> shailesh.tripathi.ec...@itbhu.ac.in> wrote:
>>
>>> Hello,
>>> Please review my proposal for project "OpenCL GPGPU raytracing" in
>>> GSOC,2017.
>>> In the proposal, the code work flow chart is left. I will complete it by
>>> today.
>>>
>>> Thanks in advance!
>>>
>>> Regards
>>> Shailesh
>>>
>>> Shailesh Tripathi
>>> B.Tech. Part-IV
>>> Electronics Engineering
>>> IIT-BHU (Varanasi)
>>>
>>> On Tue, Mar 21, 2017 at 9:36 AM, Christopher Sean Morrison <
>>> brl...@mac.com> wrote:
>>>
>>>>
>>>> > I am Shailesh Tripathi pursuing B.Tech. (Part-IV) in Electronics
>>>> Engineering from IIT-BHU, Varanasi, India. I am looking forward to apply
>>>> for GSOC,2017 for the project "OpenCL GPGPU raytracing”.
>>>>
>>>> Thanks for the introduction Shailesh.
>>>>
>>>> > Currently I am working on porting the primitive "hrt". Other than
>>>> selecting as much primitives as possible to port in the time frame, I am
>>>> looking forward to add a feature of automatic GPU device selection in case
>>>> of multi-GPU system on the basis of a few parameters which would choose the
>>>> most powerful GPU of all (the parameter selection needs more thinking,
>>>> probably selecting the one with maximum global memory would be helpful). I
>>>> am looking forward for other optimizations too.
>>>>
>>>> Note that because we’re using OpenCL means that we’re not just limited
>>>> to selecting or relying on GPU devices. We want to be able to take
>>>> advantages of all available computational resources.
>>>>
>>>> > I have some experience in GPGPU computing, CUDA and OpenCL, and
>>>> OpenGL. I am trying to learn CAD and ray-tracing techniques.
>>>>
>>>> Great! Look forward to seeing a code modification and details of your
>>>> proposal.
>>>>
>>>> Cheers!
>>>> Sean
>>>>
>>>>
>>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> BRL-CAD Developer mailing list
>> brlcad-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>>
>>
>
>
> --
> Vasco Alexandre da Silva Costa
> PhD in Computer Engineering (Computer Graphics)
> Instituto Superior Técnico/University of Lisbon, Portugal
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
