Re: [brlcad-devel] [GSOC 2015] Participant - Materials Database Project
On Mar 23, 2015, at 2:18 AM, Chinmaya Patanaik patanaikchinm...@gmail.com wrote: I am a first year masters student from Prague, Czech Republic. I am interested in contributing to 'Materials Database' project under BRL-CAD. Welcome Chinmaya! I went through the github repository. It seems an initial version has been created using PHP. I was thinking of implementing it using Python/Django and any robust database such as Mysql or Postgresql. Language is but an implementation detail. You should focus on what features, improvements, goals you aim to achieve. Translating everything the current implementation does from PHP to Django without making any improvements would not be a desirable proposal. I would really appreciate if someone can guide me in the right direction. The best way is for you to set up the current Materials Database code, get it working, and see how you would improve it. I believe the current system also integrates with Mediawiki too so that’s another consideration. Your proposal should be as details as possible. See prior year proposals for examples. You may also want to look at our mailing list archives as the materials database effort has been discussed a few times recently. Cheers! Sean -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Re: [brlcad-devel] Mediawiki 3D Geometry Extension
Welcome Aarti! On Mar 22, 2015, at 2:24 PM, Aarti K. Dwivedi ellydwivedi2...@gmail.com wrote: I completed GSoC 2013 with Wikimedia and GSoC 2014 with Portland State University. Any reason you haven’t continued to work with either/both of them? Can someone please guide me to a page detailing the project Mediawiki 3D geometry extension”? The title to every topic on our ideas page links to a page with more details. If it’s a red one, then it’s not a topic that has more detail yet and you have room to propose something. Cheers! Sean -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Re: [brlcad-devel] Real-Time Ray Tracing
On Mar 21, 2015, at 12:55 PM, Vasco Alexandre da Silva Costa vasco.co...@gmail.com wrote: I looked some more at the code and yeah the weave booleans step is branch heavy and has gotos in it. So this is most likely a bad candidate for GPU acceleration since a GPU will have like a quarter of the clockspeed and worse branch prediction hardware than the CPU. We want something that is compute heavy and has low thread divergence. I wouldn’t discredit it because of how it’s currently implemented. Similar to the various research demonstrations years ago that showed how to encode a (branch-heavy) kd-tree efficiently on the GPU, it should be possible to do the same with Boolean weaving. The algorithm is very similar to depth buffering and depth peeling. Like I said, you could almost certainly land a Siggraph or JCGT paper on this particular topic. It’s an under-explored area of research. So I think it is best to focus on ray dispatch+traversal at this time. Generate rays in bundles, traverse some sort of acceleration structure, gather hit candidate ids, and compute hit intersections on CPU. Not having the primitive tests on the GPU will reduce the performance advantage since we will spend time transmitting data back and forth though. This also sounds reasonable to me. This will almost certainly involve more modifications to our front-end application logic (and obviously replaced back-end traversal logic). Considerably more code that you’ll have to become familiar with compared with Boolean weaving, but not nearly as complicated or validation-sensitive. In the end, probably a tradeoff wash. Less code, harder algo vs More code, easier algo. Both highly valuable, so propose whatever piques your interest! The shading pass also seems like low hanging fruit. We need to send the image data to the GPU to display anyway so why not let it do some of the work. But this depends on how the code is organized and output is displayed. For some shaders, this is certainly possible, but I’m not married to our shader system. More inclined to leverage someone else’s rendering infrastructure (e.g., OSL and/or Appleseed) for anything other than simple phong/flat shading. The main issue is that we would like that the shootOneRay-traverseScene-evalHits-weaveBooleans-colorizePixel steps would be done in clearly separated stages for all tested rays, in order to reduce the amount of CL kernel calls and maximize coherence, but from what I understand everything currently happens in one giant megakernel. So perhaps a lot of effort should be spent changing this way of things before doing any CL coding at all. Almost certainly. There’s a front-end layer (rt) that dispatches to a back end layer (librt) for traversed intersections, then the front-end sends the results to another layer (liboptical) for coloring/effects, and that all is then composited by the front-end into an image (via libicv/libfb). The application layer (used by dozens of applications) is somewhat relevant and described in detail here: http://brlcad.org/wiki/Developing_applications Cheers! Sean -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
[brlcad-devel] My GSOC proposal for Synchronize Wiki with Docbook
@Sean, Cliff I have written my gsoc proposal. I needed your help regarding my gsoc proposal please tell me about new update regarding my work which are not mention in proposal as well as structure of proposal. Please tell me about any other module (if any ) which I need to add in my proposal. There is link https://docs.google.com/document/d/19oHpZ8jblVPKUnsMpdSvHBxKdtNdHe-zGdMCqiiIz-w/edit?usp=sharing -- Hitesh Sofat hiteshkumarsofat.wordpress.com (Life is a game winner is not defined, Think about present because future is not defined, unexpected things make the game interesting, if everything goes right then game is boring ) -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Re: [brlcad-devel] [GSOC 2015] Participant - Materials DatabaseProject
Hi Sean, Currently I am setting up the project on my local system. I went through last year's proposal and I have some new ideas that I would like to mention. Some of the major features that I want to work on are listed below. 1. User signup/login using their social media accounts(Google, Facebook, Twitter). Use OAuth for user authentication. There are a lot of excellent django libraries available such as django-allauth, django-social-auth etc. 2. Add admin functionality using django admin interface and customize it by developing new forms. 3. Design and Develop REST APIs. There are many open source libraries available such as django-rest framework or django-tastypie etc. 4. Email notification to user corresponding to any change in the database. 5. Automate installation and deployment process. Explore various options such as Shell scripts, Python Fabric or a configuration management system such as Chef, Ansible or Puppet. I would really appreciate your opinion on them to improve my proposal. Thanks, Chinmaya On Mon, Mar 23, 2015 at 3:45 PM, Christopher Sean Morrison brl...@mac.com wrote: [image: Boxbe] https://www.boxbe.com/overview This message is eligible for Automatic Cleanup! (brl...@mac.com) Add cleanup rule https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Ftoken%3DD%252FskhDvnRA7HhQPECubffTPvYpujU%252BBHp0wwNALUT2Xx0fJugRDCXJF3NaalImjfv%252FQpp1SRKKfwud0X8kqnfUQdJINIwwEg2J5M1R7%252BFiK%252FNyWbkiCjnu5w3Cnyu2NS%252FM37zpKGjCc%253D%26key%3DwIci1HU%252Bqb6HtrMZFpBeD9xoeadPsDLE%252BVN2I3KyfZU%253Dtc_serial=20800443105tc_rand=1797364912utm_source=stfutm_medium=emailutm_campaign=ANNO_CLEANUP_ADDutm_content=001 | More info http://blog.boxbe.com/general/boxbe-automatic-cleanup?tc_serial=20800443105tc_rand=1797364912utm_source=stfutm_medium=emailutm_campaign=ANNO_CLEANUP_ADDutm_content=001 On Mar 23, 2015, at 2:18 AM, Chinmaya Patanaik patanaikchinm...@gmail.com wrote: I am a first year masters student from Prague, Czech Republic. I am interested in contributing to 'Materials Database' project under BRL-CAD. Welcome Chinmaya! I went through the github repository. It seems an initial version has been created using PHP. I was thinking of implementing it using Python/Django and any robust database such as Mysql or Postgresql. Language is but an implementation detail. You should focus on what features, improvements, goals you aim to achieve. Translating everything the current implementation does from PHP to Django without making any improvements would not be a desirable proposal. I would really appreciate if someone can guide me in the right direction. The best way is for you to set up the current Materials Database code, get it working, and see how you would improve it. I believe the current system also integrates with Mediawiki too so that’s another consideration. Your proposal should be as details as possible. See prior year proposals for examples. You may also want to look at our mailing list archives as the materials database effort has been discussed a few times recently. Cheers! Sean -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
[brlcad-devel] [GSOC 2015] Participant - Materials Database Project
Hi, I am a first year masters student from Prague, Czech Republic. I am interested in contributing to 'Materials Database' project under BRL-CAD. I am comfortable with Python and various web development technologies. I also have decent experience in building apps using Django framework. I have been using Linux and git for the last 2-3 years. More information about me can be found from my personal webpage http://chinmaya.pythonanywhere.com. I went through the github repository. It seems an initial version has been created using PHP. I was thinking of implementing it using Python/Django and any robust database such as Mysql or Postgresql. I would really appreciate if someone can guide me in the right direction. Best Regards, Chinmaya Kr. Patanaik Faculty of Mathematics and Physics, Charles University in Prague, Czech Republic -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Re: [brlcad-devel] Combination in LIBRT
Hello! I have submitted my proposal on Melange. Do take a look whenever possible. I have not yet understood how exactly am I going to code this thing while the idea is pretty clear to me. I'm not able to visualize how the code would look like. I'm working on it and will get back to you about it soon. With Regards, Kalpit Thakkar On Sun, Mar 22, 2015 at 5:07 PM, Kalpit Thakkar ceasy...@gmail.com wrote: Hey! I have been looking at the files viewweight.c and gqa.c since yesterday. So, according to what I understand, I have to implement one function (or maybe two) for each of the classes in coreinterface, which would use the rtweight methodology to calculate the volume and centroid of the Database object using sampling and raytracing -- keeping in mind that while running the algorithm after getting the object from the tree (actually a DAG), I don't mutate the object as it will mutate the tree and would create problems (maybe I can make them const, as I would have to access their properties only and not perform any mutating operations). After this is done, I can add the corresponding virtual functions in Object class, enabling runtime polymorphism. I hope I'm following this correctly. Please correct me if I'm not following. One more thing, does doing this mean I would need a density file for each Database Object whose features are to be found? Because, while finding the centroid, it uses the weight calculated it seems and we would need a density file when we need to find the centroid. With Regards, Kalpit Thakkar PS : Do you think it would be possible to complete this rtweight part and implement two new classes as well or it would be too much to ask given the GSoC timeframe? On Sat, Mar 21, 2015 at 11:56 PM, Kalpit Thakkar ceasy...@gmail.com wrote: Hello Daniel! Yeah, that sounds like a good idea. Essentially, we wouldn't have different solution prototypes for primitives (as combinations use the rtweight methodology for an analytic solution), which would make it easier to add the table functions in the Object class, and the code would also be understood better. Nice! :D However, I will have to take a look at it in detail, because I don't exactly know how the code works in the rtweight methodology. Muchas Gracias :'D Yes, I'll be meticulous in my approach. I would make sure I don't mutate the objects in the tree. :) With Regards, Kalpit Thakkar PS : Whenever you take a look at the proposal, please do tell me if I need to make changes / add something. :) On Sat, Mar 21, 2015 at 11:01 PM, Daniel Roßberg danielmrossb...@gmail.com wrote: Kalpit, Implementing the missing functions for centroid, volume and surface in librt for the primitives can be highly non-trivial. How about implementing the rtweight methodology etc. fall-backs for every element in librt where an analytic solution is missing? After doing so you only had to add the appropriate table functions to Object in the C++ interface. However, you should be careful with your algorithm. It shouldn't change the elements selected with rt_gettree(). This would cause a dangerous side effect. Regards, Daniel 2015-03-21 12:32 GMT+01:00 Kalpit Thakkar ceasy...@gmail.com: Hello Sean! I figured it would be better to get your comments on the doc itself. So, here is the Google Doc link : https://docs.google.com/document/d/1RgUDxU3x3IC1r9lba49IlKP9-wJ2PCgAbcwlj7wTlTo/edit?usp=sharing With Regards, Kalpit Thakkar -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Re: [brlcad-devel] GSoC 2015 Introduction
On Mon, Mar 23, 2015 at 5:46 PM, Ilinca Andrei andrei.ilinc...@gmail.com wrote: Hello, I have been reading, documenting, doing research and speaking with OpenSCAD mentors a lot these days and I've managed to come up with following solutions and conclusions regarding the OpenSCAD Importer project : 2) OpenSCAD has a C++ parser that theoretically can be extracted and used in a common library. The only problem would be that its dependencies are huge and it would go way beyond a GSoC project to extract it from the main codebase. For example, there are about 20-30 classes using that and I would need to refactor them as well, in a way that a change in OpenSCAD code wouldn't break the library neither for them, nor for BRL-CAD. This is possible but, as even a GSoC project alone, it won't bring any immediate benefit to any of this orgs. I would caution against ruling out all code reuse from OpenSCAD - if there are a few relatively self-contained bits (say, some scad language constructs) that could be isolated and re-used in a new framework, that would still be effort saved. Sometimes you can change the data types in a complex bit of code from theirs to your local versions and save a lot of effort... 3) Another solution would be to build a slim API on top their dependencies and have BRL-CAD maintain that as part of OpenSCAD. But for the library to be used by BRL-CAD it would mean relicensing half of OpenSCAD to BSD/MIT which is not currently an option for them. I don't know how deep their dependencies are wired in, but remember you don't actually need in this layer any of the code for actual boolean evaluations (for example - I believe they use opencsg for that?). You just need to parse the files and build an in-memory structure. Conclusion: as far as making something usable, integrated, easy to maintain and valuable for BRL-CAD (and potentially for them too), making it from scratch, using only existing BRL-CAD tools for help is the best option out there for this GSoC project. That's OK as a way to start, especially for the .csg stage, but once you get to the scad language I'd keep an eye open for separable bits that they might be comfortable re-licensing that you could leverage in your new work. After reading some more about the lexical and syntactical analysis , about how a parser is created and implemented and also about the AST tree that is generated, my plan (as recommended by OpenSCAD community) is to start by making a C++ importer for *.csg files and then extend it to cover all the *.scad features. I think starting with the simpler format is a sound idea. Can OpenSCAD step down a .scad file to a .csg file as an export option? The interesting part would come when I will have to save the info from the tree to .g format and I hope the BRL-CAD community could help me with info about the API and the geometry insights. I can research on my own but it will take considerably longer time. Our existing importers should give you a lot of insight into that process - they all have to make the same mappings. We can guide you more specifically if you hit problems, but the the intaval converter (src/conv/intaval) might be a good place to start looking for examples. If I recall, it's got the code broken out into read external format and write .g file parts. Cheers, CY -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Re: [brlcad-devel] My GSOC proposal for Synchronize Wiki with Docbook
Hitesh, It’s clear that taking the initiative to get involved months ago has helped you research and understand the requirements of what you’re proposing. Well done. The overall structure is fine. As to your technical approach, I’d personally prefer to not involve MySQL at all for change management. Using directory queues on the server (one for holding changes pending review, another for those approved for commit), would probably be sufficient: patch files — basically an on-disk file database instead of relational. This would let a dev on the server manually inspect and fix, for example, if there were a merge conflict. Plus, it’s just simpler to maintain — don’t have to worry about mysql permissions, wouldn't force devs to work through a web browser, don’t have to worry about mysql updates, etc. Your development schedule looks reasonable, but it’s much easier to track if you break the schedule up in terms of weeks (instead of 10-day blocks). There are four bonding period weeks and twelve coding weeks. Can you characterize your schedule in those terms? A little more detail is needed in a few places including how the back-end will be structured (maybe a diagram) and interact with the front-end. You are primarily proposing a custom web application but don’t really describe the implementation (language? framework? plugin?) or interface much (prototype user interface mock-up and/or diagrams would be helpful). You can utilize the bonding period to sort out the user interface and content in more detail so once the coding weeks begin, you are almost entirely writing code. The first 30 days (4 weeks) you propose converting all txt, html, latex, and manual page docs, but that’s really out-of-scope for the coding weeks. That conversion work should either be during the bonding timeframe, left to others so you only focus on existing docbook, or you could propose writing scripts to help convert them. We definitely want them all converted and I’d love for you to do that conversion, but the GSoC coding weeks must primarily consist of writing code. I suggest limiting your schedule to no more than two weeks of non-coding activities (and that includes time writing a midterm and final report, having discussions, testing, etc). You also don’t itemize which docs or how many or how big they are, relatively speaking. It obviously should (eventually) be all of them, but I know you’ve been looking at this all a lot already and can probably be specific. If you can, that will help demonstrate the scope of this effort to others. I suggest eliminating sorting. The priority should be focused on 1) publishing our docbook docs online, 2) allowing those documents to be edited online or directly in the repo, and 3) having any committed edits automatically reflected/republished online. Anything else is secondary and could be done after 1/2/3 are robust, especially with moderation occurring after online edits from #2. I do appreciate that you pushed adding new docs to near the end of your timeline, but it’s also another candidate for elimination. That’s time better spent on making the round-trip publishing more robust and featured, ready for production use. I’m also VERY interested in seeing you discuss how this will (or will not) interact with a content management system — mediawiki, wordpress, and/or confluence. If you’ve done any research with any of those three, please include them in your proposal discussion. I would have thought writing a plugin for one of those would be more desirable than something entirely custom, even if it meant not using some Docbook tags. So if you’ve determined custom is better, I’d like to see you discuss that analysis in detail. Overall Cheers! Sean -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Re: [brlcad-devel] [GSOC 2015] Participant - Materials DatabaseProject
On Mar 23, 2015, at 11:39 AM, Chinmaya Patanaik patanaikchinm...@gmail.com wrote: • User signup/login using their social media accounts(Google, Facebook, Twitter). Use OAuth for user authentication. There are a lot of excellent django libraries available such as django-allauth, django-social-auth etc. If the current system is a mediawiki plugin, then social media / oauth login is already possible. • Add admin functionality using django admin interface and customize it by developing new forms. New forms that do what? Compared to the current, I’m not sure what that means. • Design and Develop REST APIs. There are many open source libraries available such as django-rest framework or django-tastypie etc. You’d also have to elaborate on what exactly this would provide that is not currently provided, and maybe provide examples. • Email notification to user corresponding to any change in the database. I believe this is already possible. • Automate installation and deployment process. Explore various options such as Shell scripts, Python Fabric or a configuration management system such as Chef, Ansible or Puppet. This could be useful. However, it’s not something that affects users too, so not a primary consideration. I reiterate my earlier concern that this should not be a django exercise, justifying how everything will be easy to do in django. I suggest thinking through “what” in more detail before even considering “how”. The focus first is on requirements — what you are going to accomplish as it pertains to users and developers (with emphasis on users). You covered some of that, but it feels incomplete. How you aim to implement the requirements is something you can elaborate later in your proposal when it’s more clear what the benefit and bigger picture looks like. Cheers! Sean -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Re: [brlcad-devel] GSoC 2015 Introduction
Hello, I have been reading, documenting, doing research and speaking with OpenSCAD mentors a lot these days and I've managed to come up with following solutions and conclusions regarding the OpenSCAD Importer project : 1) The idea of using the FreeCAD LGPL python parser and implementing it into BRL-CAD code base is a *no-go*. It would imply using the python code already existent for parse() and writing another python logical component for creating the evaluation step of the process, the traverser from the AST tree to .g format and would also be something hard to integrate in to the existing conversion toolchain (which is based on C/C++ files). In my opinion, it doesn't sound right to develop a python evaluator when BRL-CAD requires python bindings anyway. 2) OpenSCAD has a C++ parser that theoretically can be extracted and used in a common library. The only problem would be that its dependencies are huge and it would go way beyond a GSoC project to extract it from the main codebase. For example, there are about 20-30 classes using that and I would need to refactor them as well, in a way that a change in OpenSCAD code wouldn't break the library neither for them, nor for BRL-CAD. This is possible but, as even a GSoC project alone, it won't bring any immediate benefit to any of this orgs. 3) Another solution would be to build a slim API on top their dependencies and have BRL-CAD maintain that as part of OpenSCAD. But for the library to be used by BRL-CAD it would mean relicensing half of OpenSCAD to BSD/MIT which is not currently an option for them. Conclusion: as far as making something usable, integrated, easy to maintain and valuable for BRL-CAD (and potentially for them too), making it from scratch, using only existing BRL-CAD tools for help is the best option out there for this GSoC project. After reading some more about the lexical and syntactical analysis , about how a parser is created and implemented and also about the AST tree that is generated, my plan (as recommended by OpenSCAD community) is to start by making a C++ importer for *.csg files and then extend it to cover all the *.scad features. The interesting part would come when I will have to save the info from the tree to .g format and I hope the BRL-CAD community could help me with info about the API and the geometry insights. I can research on my own but it will take considerably longer time. I will bring the updates needed to my proposal asap and hope for a review to correct any issues that might appear. PS: I added a new patch https://sourceforge.net/p/brlcad/patches/329/ a few days ago regarding the object oriented approach of my basic importer. It basically uses an object to takes care of the reading and writing from the input to the output. I would really appreciate your opinion on that, as well as a review/feedback on my (new/old) proposal. Regards, Andrei On Fri, Mar 20, 2015 at 11:59 PM, Christopher Sean Morrison brl...@mac.com wrote: On Mar 19, 2015, at 7:33 PM, Ilinca Andrei andrei.ilinc...@gmail.com wrote: Kintel advised me to aim towards creating a common parser for both openscad and brl-cad and relicense that as LGPL or BSD/MIT. He said we could either refactor existing openscad code into a clean component, or rewrite the parser and retrofit it into openscad. The former is a bit messy but safer - the latter would be preferable but is likely a fair bit of work. What is your advice regarding this matter? We would prefer bsd/mit license, but as far as which approach would be better — that’s not something I can fully answer without researching the situation in depth. All I can offer is industry observation. You being unfamiliar with the existing code will undoubtedly be biased towards a rewrite. That’s a position *most* programmers prefer taking when presented with a refactor vs rewrite. However, most research on the subject has shown it’s nearly always better to refactor. Exceptions are when you’re changing entire paradigms, sometimes when you’re changing languages, or when it’s just not very much or the code is young. The bigger and more mature the code, the less likely it’ll be cost effective. That said, I know very little about the modular status of their code, its age/maturity, its complexity, or the level of effort that might be involved. Just recognize your own bias when estimating, and if you work with them to estimate that effort, you should be able to answer the question better than anyone. Summary: break down both those options into a set of at least 10 subtasks and estimate how long each might take, show them your estimates and see if they concur, then you’ll have a better plan on how to proceed. I understood a bit more about their internal structure (their compile table https://github.com/openscad/openscad/blob/master/doc/OpenSCAD-compile.pdf was very useful too) and there are 2 types of OpenSCAD files: *.scad- normal ones, providing the full list of features and
Re: [brlcad-devel] Mediawiki 3D Geometry Extension
Hi! The GSoC 2014 project was like a standalone project and I am currently working on extending VisualEditor to Wikisource. Is there any basic expectation from the extension that the community has? Cheers, Aarti ᐧ On Mon, Mar 23, 2015 at 8:17 PM, Christopher Sean Morrison brl...@mac.com wrote: Welcome Aarti! On Mar 22, 2015, at 2:24 PM, Aarti K. Dwivedi ellydwivedi2...@gmail.com wrote: I completed GSoC 2013 with Wikimedia and GSoC 2014 with Portland State University. Any reason you haven’t continued to work with either/both of them? Can someone please guide me to a page detailing the project Mediawiki 3D geometry extension”? The title to every topic on our ideas page links to a page with more details. If it’s a red one, then it’s not a topic that has more detail yet and you have room to propose something. Cheers! Sean -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel -- Aarti K. Dwivedi -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
[brlcad-devel] Plate Mode NURBS raytracing
Hello Sean! I was thinking of proposing another project and I would like to work on this project. I checked past 3-4 years' projects, but there hasn't been any efforts in this direction. So, according to the description there, BoT has a raytracing routine that, when finds an in point for a ray, due to extremely thin surface, assigns the out point as the in point + the implicit thickness added to each coordinate of in point and I would have to implement the same methodology for NURBS surfaces now. To analyze the problems that I would face in implementing the plate mode raytracing for NURBS, I would have to understand exactly how raytracing NURBS works. So, is there any specific resource that might help me understand this aspect quickly? I did some quick searches and found this paper : https://www.cs.utah.edu/~shirley/papers/raynurbs.pdf Will this help me understand the raytracing NURBS fairly enough? With Regards, Kalpit Thakkar -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Re: [brlcad-devel] GSOC'15: NURBS Editing Support
Nihar, this is a lot of highly involved technical questions and not really much time to get into detail. I suggest you just research as much as possible to understand approaches and make a proposal to the best of your understanding. That said, I’m not sure any of this is answerable without knowing what specific user feature you are aiming for. “NURBS Editing” can mean many many things, you have to define a set of objectives. On Mar 23, 2015, at 11:52 AM, Nihar Mehta niharmeht...@gmail.com wrote: 1.Can we apply the following algo for trimming surfaces? It’s not clear to me at all what problem you’re addressing or what NURBS editing operation this relates with. The paper you refer is about trimming a subdivision surface. We already utilize a trimmed NURBS surface boundary representation and evaluate those trims in a variety of ways. 2. Can we use the following second order algo for Orthogonal projection onto a curve and Orthogonal projection onto a surface? Orthogonally projecting onto a curve/surface for what purpose? 3. Can adding a symmetry tool be pertaining to this project? You can propose whatever you like, but symmetric editing is definitely not a priority. We don’t have any editing. 4. Can we use this or is it patented? [Algorithms for Blending Surface Generation] Given it’s a DTIC thesis, almost certainly not relevant to generalized NURBS editing. He describes creation of fillet surfaces (which would be awesome AFTER we have general NURBS editing. 5.Which of the followng are not provided in the current code and are desirable to be implemneted? Normally, I’d say this is exactly what you are supposed to research yourself. But this is a crazy complex topic and even more complex code, so I’ll save you some time. None are provided. Most are desirable. I have a feeling you’re way overthinking algorithmic approaches before even running BRL-CAD. We need very basic editing support. Grab a corner of a box and move it. Grab an edge and move it. Grab some point on a surface and move it. Do any of those without destroying the integrity and continuity of the neighboring edges/surfaces. Not easy. Cheers! Sean -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Re: [brlcad-devel] Plate Mode NURBS raytracing
On Mar 23, 2015, at 2:05 PM, Kalpit Thakkar ceasy...@gmail.com wrote: Hello Sean! I was thinking of proposing another project and I would like to work on this project. I checked past 3-4 years' projects, but there hasn't been any efforts in this direction. Indeed. It’s not a hard project, algorithmically speaking, but nobody has yet put forth a quality proposal to work this area. So, according to the description there, BoT has a raytracing routine that, when finds an in point for a ray, due to extremely thin surface, assigns the out point as the in point + the implicit thickness added to each coordinate of in point and I would have to implement the same methodology for NURBS surfaces now. To analyze the problems that I would face in implementing the plate mode raytracing for NURBS, I would have to understand exactly how raytracing NURBS works. So, is there any specific resource that might help me understand this aspect quickly? Nope. Understanding how NURBS ray tracing works is not something that can be achieved quickly. But you don’t really need to understand it. You need to understand what plate-mode means — and more specifically you need to understand BRL-CAD’s existing plate-mode implementation for triangle meshes. If you understand that, you’ll know exactly what is needed for NURBS plate mode, even without understanding NURBS ray tracing. This requires a lot of reading of code and playing with sample geometry. Cheers! Sean -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
