“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.

Hello Everyone,

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

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.

This year we try a new approach and created a common platform under the name OpenCAx for cross-cutting concerns. We use the OpenCAx term for quite some time, but now it becomes more clearer.
Beside the information from Google at https://summerofcode.withgoogle.com/ we have additional content for students at https://opencax.github.io/.
Project ideas are listed under https://github.com/opencax/GSoC/issues and especially for LibreCAD one can filter by project.

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.

The LibreCAD Team