WHAT WORK IS DONE? “Quick Recap” There are a lot of commits made , these are the ones with major milestonesreached Making a Viewport System: a589542 User-Device Coordinate System: f0b2787 Saving/Restoring Context-Management: 8af6bcc Matrix transformations: da330e5 Paper-Background: 5c28e68 Caching-Mechanism for accelerated rendering: 4a402df Basic GL_Entity: dec9c97 Gradient Entity for gradient background: fd9c35f Gradient_Shader: b75f17f Shader’s book to save all different shaders: 6b44b40 Shader based Thicklines with miter joints: c680b7e Shader based dash-Gap Line-Patterns: 7a8d468 Transparency with alpha channel: 16d4d31 Font_Book to store different font styles: 665a3a3 Text Entity for text rendering: 35d318d Text-Rendering: b13289d Beziér Curves (linear, quadratic, cubic): 15af822 Arcs: 470c15c Ellipse: 4b43e5f
WHAT WORK IS LEFT? Me and my mentors Florian and Armin are working to make code more cleaned , Testing , abstracting some parts , following some standards, removing code duplication , code refactoring.
“Major Challenges finished” During Phase 2 the most hard challenges were accomplished. Which required a lot of research and finding multiple ways to implement them. Mentors kept patience and belief in me and gave me opportunity to work on my pace. The major challenges finished till now were- –> Thicklines –> Shader based thick polyline with miter joints –> Shader based Dash-Gap line patterns
“We need to write some Text” This was the major work to be done as phase 3 starts. Getting a simple string to render on screen is quite difficult with a low-level library like OpenGL. In LibreCAD there is no limit for characters and extended characters are used often for like mathematical expressions. Once you think about all these complicated matters of text, it wouldn’t surprise you that this probably doesn’t belong in a low-level API like OpenGL.
“Going with Textures” So the basic idea behind text rendering is to store the textures corresponding to each character and also its information of coordinates and dimension.(Collectively known as glyphs ) . Not only this glyph data , my idea extended to even cache them as vertex buffer in GPU along with texture. This will not require to generate them at each frame and i just used matrix translations to render them at the perfect position. And to generate the texture i used the Freetype library. FreeType is a software development library that is able to load fonts, render them to bitmaps and provide support for several font-related operations. Finally we got nice font rendering with extended characters too.
“Rendering curves” Now it was time to finish some missing functionalities of the opengl painter which includes curves, bezier , quadratic , cubic , ellipse etc. As the core part was already done adding these functionalities on the topmost layer was not that hard , it required some mathematics though.
“Testing before Integration” So now the painter was ready and it was time for cleaning code, following standards, code refactoring, unit testing etc. Initially there were some issues on building against the Travis CI , but Florian helped me a lot in this. The code was building successfully. The OpenGL Rendering works fine. Overall during the last phase my learning curve got higher. I came across different things, from very simple to hard, how code is made standard, using tools like Travis ,CodeFactor My Mentors really helped me in learning these things and use them.
“What happening after this” – the work left Me and Florian are working to make code more cleaned , abstracting some parts ,following some standards, removing code duplication , code refactoring. These are small but important things . After that there is more work like user defined textures ,MSDF font rendering(if needed) etc.
“Getting the right basis before jumping into action” And that’s the reason for the successful finish of Phase 1st. Mentors help was amazing during this period. We got the correct base for the project and finished most of the basic but the major things which will decide the implementation of upcoming challenges.
The things completed till now were– –> Basic painter following the predefined layout (outermost layer) –> A strong Renderer class ( which is the core and everything will moves around this) –> Viewport System ( User-Device-User coordinate system) –> Matrix Manipulation ( involves a lot of matrix and vector math ) –> Caching mechanism (Crucial part which now enable us high performant rendering ) –> Gradient Rendering
“Feeling the graphics pipeline ;)” Although even before starting the project i had used and planned the Modern OpenGL way for implementation. But As the Phase 2 period started i figured out that a lot more simple and familiar functionalities are been “replaced with nothing”!!! And actually it required implementing things using completely scratch and following graphics pipeline. And here starts the experience of deprecated functionalities of such a low level API. It became more understandable the difference of Legacy and Modern OpenGL and how computer graphics actually works.
“Seriously…Rendering Lines is not easy :)” Simpler the things seems , the complex they are. It was all going good, rendered lines seems very nice until i came across ThickLines. So basically in LibreCAD we have standard linewidths whose thickness can/cannot get enlarged on zooming (its up to the requirement ). Ultimately we needed lines rendered with variable thickness. Now Initially i have planned to simply implement this using the given functions in OpenGL API (glLineWidth().. which is deprecated ). I discussed alot with the mentors about the strategy( and seriously their guidance at this moment decided the later implementations ) It required almost revamping the codebase at both the CPU and GPU side. On CPU side the GL_LINES/GL_LINE_STRIP/GL_LINE_LOOP were replaced by the GL_LINE_STRIP_ADJACENCY and changing the way renderer works for this. Then passing the data to GPU , then to Vertex Shader to Geometry Shader to finally Fragment Shader. Basically using 2 triangles for a line, using mitter joints (which required geometry math in shader) and finally it worked.
“Dash – Gap – Dash — — — “ Linepatterns or dash patterns. Here also initially i thought it would be easy and i can use glLineStipple()..( Ah..which again is depreciated : | and actually it can’t render every possible pattern which is the requirement of our LibreCAD , here the user can even generate its own linepattern ) Now this was even more harder , the patterns has any possible combination and that too seamless. So what i did was storing the path length of the point along with their coordinates , passing data from CPU to GPU ( vertex shader -> Geometry shader -> Fragment shader , using the texel coordinates for deciding the dash and gaps and Finally abstracting it properly. And Yes there can be multiple ways but this suits best for LibreCAD (at least till now), there are another method(s) like 1D Texture etc.( But the codebase is designed to support those methods and it will only require changes in GPU side or shaders) “How it looks now”
Overall the 2nd Phase was much more challenging and required more research work before actually coding it. For even simple changes it required a lot revamping code. Regarding mentors , Armin helped me a lot in understanding the requirements and explaining stuff( which he does very well 🙂 and is also very concerned about the standards. And Florian is always there for guiding me like always (and is quite friendly and cool 😉 ). For example during this phase we encountered a strange bug(on different graphic cards ) It was almost unreachable for me but he helped me in fixing that step by step, almost a week went into it but finally we got more robust and refined code!!! The next work to be done is Text Rendering and finishing the remaining painters methods and much more. My college re-opened , getting less time as compared to i was giving till now but will try to manage.
This year’s LibreCAD GSoC project involves the integrating pure OpenGL rendering module in “LibreCAD version 3”. Before the official coding period began i did a lot of research work , discussions with mentors regarding the project , did some setup and implemented some basic things. Initially with the research work and planning the project seems to be very challenging. The overall thing about rendering module involves to manage data in CPU and GPU as well. Manipulation like Sending, saving , deleting the data corresponding to entities in CAD kernel of LibreCAD 3. –>The major milestones in “Phase 1” planned and finished are —-
Follow the LcPainter layout for OpenGLpainter First challenge was to design the OpenGL Rendering module so that the rendering draw() codes should not be hindered and follow the LcPainter layout. For this thing I designed a number of classes . The most important are gl_entity( The one which hold the data in CPU and GPU) , renderer ( The one which actually builds the gl_entities ) , LcOpenGLPainter ( It is the uppermost layer which implements LcPainter )
Matrix manipulations and context saving The Renderer have the projection and view matrix. There is also a CTM ( Current transition matrix) used for transitions. There is also case of Isolated Transitions for which i implemented the context saving using stack implementation which saves and restores context.
Correct viewport & Coordinate System Basically there are two coordinate system. First the Device Coordinate System (Downward Y as +ve) and the second is the User Coordinate System(Downward Y as -ve). Implemented multiple functions that convert Device to user Coordinates and vice versa using manipulations on CTM.
Caching Mechanism This was the biggest challenge to cache the entities. Basically the idea was to don’t go through the draw() code of entities again and again. This will stop the repetitive sending of data from CPU to GPU. The entities in LibreCAD can be simple(line,circle,..) to complex (dimensions etc..) . For thing i implemented separate classes gl_pack (to store gl_entities), cacher (which generates gl_pack and save them with an ID= entity id in kernel), cacherpainter which also implements LcPainter and used for caching but it doesn’t render anything, it only saves data. When an entity is already cached it is then rendered using already saved cached gl_pack
Gradient Rendering Besides Shape Entities there are possibility of entities which have gradient ( mostly gradient background..which uses linear gradient).For this i created a class Gradient_Entity which also implements gl_entity. It holds data of linear gradient and calculates the (R,G,B,A) data for each vertex using some vector mathematics ( dot product , scalar projection etc
So Phase 1 is finished and below is a comparison of Cairo (Existing) and opengl rendering (implemented till Phase 1 ) in LibreCAD 3
The upcoming challenges are Shader based Linepatterns, dashes and Text Rendering.
Overall within 1st Phase alot of work happened and i really thank my mentors Armin and Florian . They always help me , discuss almost every doubt before writing code , gave me ideas whenever i got stuck during coding and keeping a cool environment. GSoc Dev Log- dev_log About me – Kartik_Kumar
LibreCAD is a free Open Source CAD application for Windows, Apple and Linux. It allows industrial designers and graphics enthusiast to create CAD projects of the highest standard and precision. With this precision and standard comes the need of high quality and accelerated rendering to visualize a document.
This year during GSoC the project consists of making a complete well abstracted OpenGL implementation with C++ for the rendering in LibreCAD 3.
As the coding period is just about to begin next week right now i am doing some more research work and debugging on how it will be implemented. Till now a partial implementation of opengl painter is done with basic features of VertexBuffer Objects, pan, zoom etc. The Project is not just about to use OpenGL but to use it in the way LibreCAD painter calls. Few challenges in this project are the caching mechanism(saving buffer objects in GPU), text rendering( ttf fonts/MSDF fonts),complex entities(dimensions etc) , gradients,spline curves and doing all of them with keeping thread safe also.
From next week as the coding period will begin i will start working on caching mechanism and making graphic entities more robust and abstracted.
A new round of Google Summer of Code is gather speed.
We are happy to announce, that once again, LibreCAD is part of GSoC in 2019!
Again, under the umbrella of BRL-CAD, a couple of CAD/CAM/CAE or short CAx organizations going to mentor students for a 3 month full time coding challenge during their summer break. The students, when they participate successfully, will gain experience, reputation and also a certificate and a stipend from Google. Our value will be the progress, bringing LibreCAD 3 to a new level and hopefully attract the participants to stay longer with us and become a regular contributor.
If you are a student who is eligible for the program, have some C++ skills and prefer coding over selling burgers, don’t hesitate to get in touch with us. Or you know one who might be interested, let him know about this great chance. Look out for Armin (LordOfBikes) or Florian (Feragon) on our community chat channels IRC #librecad or Zulip or reply to any project idea.