Articles on tvcastillod's Bloghttps://blogs.python-gsoc.orgUpdates on different articles published on tvcastillod's BlogenMon, 28 Aug 2023 21:24:09 +0000Final Reporthttps://blogs.python-gsoc.org/en/tvcastillods-blog/final-report-3/<p><a href="https://summerofcode.withgoogle.com/programs/2023/projects/ymwnLwtT"><img alt="gsoc" height="50" src="https://camo.githubusercontent.com/976f3fc0f6caea7a0818d893dd354096e2119daa4d2d761f54cf0eb428617962/68747470733a2f2f646576656c6f706572732e676f6f676c652e636f6d2f6f70656e2d736f757263652f67736f632f7265736f75726365732f646f776e6c6f6164732f47536f432d6c6f676f2d686f72697a6f6e74616c2e737667"></a> <a href="https://summerofcode.withgoogle.com/programs/2023/organizations/python-software-foundation"><img alt="" height="45" src="https://camo.githubusercontent.com/66988f1c36b26edf56d22181ffc740f7aaa5180026740ace7ee67cebe60de0db/68747470733a2f2f7777772e707974686f6e2e6f72672f7374617469632f636f6d6d756e6974795f6c6f676f732f707974686f6e2d6c6f676f2e706e67"></a> <a href="https://fury.gl/latest/index.html"><img alt="fury" height="45" src="https://camo.githubusercontent.com/d5723ed9228890fc993fd843c4e0d8233c07c1396080af8981d4a1ebc655aad5/68747470733a2f2f707974686f6e2d67736f632e6f72672f6c6f676f732f465552592e706e67"></a></p>
<h1>Google Summer of Code 2023 Final Work Product</h1>
<ul>
<li><strong>Name:</strong> Tania Castillo</li>
<li><strong>Organisation:</strong> Python Software Foundation</li>
<li><strong>Sub-Organisation:</strong> FURY</li>
<li><strong>Project:</strong> <a href="https://github.com/fury-gl/fury/wiki/Google-Summer-of-Code-2023-(GSOC2023)#project-3-sdf-based-uncertainty-representation-for-dmri-glyphs">SDF-based uncertainty representation for dMRI glyphs</a></li>
</ul>
<h2>Abstract</h2>
<p>Diffusion Magnetic Resonance Imaging (dMRI) is a non-invasive imaging technique used by neuroscientists to measure the diffusion of water molecules in biological tissue. The directional information is reconstructed using either a Diffusion Tensor Imaging (DTI) or High Angular Resolution Diffusion Imaging (HARDI) based model, which is graphically represented as tensors and Orientation Distribution Functions (ODF). Traditional rendering engines discretize Tensor and ODF surfaces using triangles or quadrilateral polygons, making their visual quality depending on the number of polygons used to build the 3D mesh, which might compromise real-time display performance. This project proposes a methodological approach to further improve the visualization of DTI tensors and HARDI ODFs glyphs by using well-established techniques in the field of computer graphics, such as geometry amplification, billboarding, signed distance functions (SDFs), and ray marching.</p>
<h2>Proposed Objectives</h2>
<ul>
<li>Implement a parallelized version of computer-generated billboards using geometry shaders for amplification.</li>
<li>Model the mathematical functions that express the geometry of ellipsoid glyphs and implement them using Ray Marching techniques.</li>
<li>Model the mathematical functions that express the geometry of ODF glyphs and implement them using Ray Marching techniques.</li>
<li>Use SDF properties and techniques to represent the uncertainty of dMRI reconstruction models.</li>
</ul>
<h2>Objectives Completed</h2>
<ul>
<li>
<h3>Ellipsoid actor implemented with SDF</h3>
</li>
</ul>
<p>A first approach for tensor glyph generation has been made, using ray marching and SDF applied to a box. The current implementation (<code>tensor_slicer</code>) requires a sphere with a specific number of vertices to be deformed. Based on this model, a sphere with more vertices is needed to get a higher resolution. Because the ray marching technique does not use polygonal meshes, it is possible to define perfectly smooth surfaces and still obtain a fast rendering.</p>
<p>Details of the implementation:</p>
<ul>
<li><em>Vertex shader pre-calculations</em>: Some minor calculations are done in the vertex shader. One, corresponding to the eigenvalues constraining and min-max normalization, are to avoid incorrect visualizations when the difference between the eigenvalues is too large. And the other is related to the tensor matrix calculation given by the diffusion tensor definition T=R<sup>-1</sup>ΛR, where R is a rotation matrix that transforms the standard basis onto the eigenvector basis, and Λ is the diagonal matrix of eigenvalues [4].</li>
<li><em>Ellipsoid SDF definition</em>: The definition of the SDF is done in the fragment shader inside the <code>map</code> function, which is used later for the ray marching algorithm and the normals calculation. We define the SDF more simply by transforming a sphere into an ellipsoid, considering that the SDF of a sphere is easily computed and the definition of a tensor gives us a linear transformation of a given geometry. Also, as scaling is not a rigid body transformation, we multiply the final result by a factor to compensate for the difference, which gave us the SDF of the ellipsoid defined as <code>sdSphere(tensorMatrix * (position - centerMCVSOutput), scaleVSOutput*0.48) * scFactor</code>.</li>
<li><em>Ray marching algorithm and lighting</em>: For the ray marching algorithm, a small value of 20 was taken as the maximum distance since we apply the technique to each individual object and not all at the same time. Additionally, we set the convergence precision to 0.001. We use the central differences method to compute the normals necessary for the scene’s illumination, besides the Blinn-Phong lighting technique, which is high-quality and computationally cheap.</li>
<li><em>Visualization example</em>: Below is a detailed visualization of the ellipsoids created from this new implementation.</li>
</ul>
<p style="text-align: center;"><a href="https://user-images.githubusercontent.com/31288525/244503195-a626718f-4a13-4275-a2b7-6773823e553c.png"><img alt="ellipsoids created with ray marching SDFs" src="https://user-images.githubusercontent.com/31288525/244503195-a626718f-4a13-4275-a2b7-6773823e553c.png" width="400"></a></p>
<p>This implementation does show a better quality in the displayed glyphs, and supports the display of a large amount of data, as seen in the image below. For this reason, a tutorial was made to justify in more detail the value of this new implementation. Below are some images generated for the tutorial.</p>
<p style="text-align: center;"><a href="https://user-images.githubusercontent.com/31288525/260906510-d422e7b4-3ba3-4de6-bfd0-09c04bec8876.png"><img alt="images for tutorial: ellipsoids zoomed, quality comparison, large amount of ellipsoids" src="https://user-images.githubusercontent.com/31288525/260906510-d422e7b4-3ba3-4de6-bfd0-09c04bec8876.png" width="700"></a></p>
<p><em>Pull Requests:</em></p>
<ul>
<li><strong>Ellipsoid actor implemented with SDF (Merged)</strong> <a href="https://github.com/fury-gl/fury/pull/791">fury-gl/fury#791</a></li>
<li><strong>Tutorial on using ellipsoid actor to visualize tensor ellipsoids for DTI (Merged)</strong> <a href="https://github.com/fury-gl/fury/pull/818">fury-gl/fury#818</a></li>
</ul>
<p><strong>Future work:</strong> In line with one of the initial objectives, it is expected to implement billboards later on to improve the performance, i.e., higher frame rate and less memory usage for the tensor ellipsoid creation. In addition to looking for ways to optimize the naive ray marching algorithm and the definition of SDFs.</p>
<h2>Objectives in Progress</h2>
<ul>
<li>
<h3>DTI uncertainty visualization</h3>
</li>
</ul>
<p>The DTI visualization pipeline is fairly complex, as a level of uncertainty arises, which, if visualized, helps to assess the model's accuracy. This measure is not currently implemented, and even though there are several methods to calculate and visualize the uncertainty in the DTI model, because of its simplicity and visual representation, we considered Matrix Perturbation Analysis (MPA) proposed by Basser [1]. This measurement is visualized as double cones representing the variance of the main direction of diffusion, for which the ray marching technique was also used to create these objects.</p>
<p>Details of the implementation:</p>
<ul>
<li><em>Source of uncertainty</em>: The method of MPA arises from the susceptibility of DTI to dMRI noise present in diffusion-weighted images (DWIs), and also because the model is inherently statistical, making the tensor estimation and other derived quantities to be random variables [1]. For this reason, this method focus on the premise that image noise produces a random perturbation in the diffusion tensor estimation, and therefore in the calculation of eigenvalues and eigenvectors, particularly in the first eigenvector associated with the main diffusion direction.</li>
<li><em>Mathematical equation</em>: The description of the perturbation of the principal eigenvector is given by math formula where <em>ΔD </em>corresponds to the estimated perturbation matrix of <em>D</em> given by the diagonal elements of the covariance matrix <em>Σ<sub>a</sub>≈(B<sup>T</sup>Σ<sub>e</sub><sup>-1</sup>B)<sup>-1</sup></em>, where Σ<sub>e</sub> is the covariance matrix of the error <em>e</em>, defined as a diagonal matrix made with the diagonal elements of <em>(Σ<sub>e</sub><sup>-1</sup>)=⟨S(b)⟩<sup>2</sup>/σ<sub>η</sub><sup>2</sup></em> . Then, to get the angle θ between the perturbed principal eigenvector of <em>D</em>, <em>ε<sub>1</sub>+Δε<sub>1</sub></em>, and the estimated eigenvector ε<sub>1</sub>, can be approximated by <em>θ =tan<sup>-1</sup>(|Δε<sub>1</sub>|)</em> [2]. Taking into account the above, we define the function <code>main_dir_uncertainty(evals, evecs, signal, sigma, b_matrix)</code> that calculates the uncertainty of the eigenvector associated to the main direction of diffusion.</li>
<li><em>Double cone SDF definition</em>: The final SDF is composed by the union of 2 separately cones using the definition taken from this list of <a href="https://iquilezles.org/articles/distfunctions/#:~:text=Cone%20%2D%20exact,sign(s)%3B%0A%7D">distance functions</a>, in this way we have the SDF for the double cone defined as <code>opUnion(sdCone(p,a,h), sdCone(-p,a,h)) * scaleVSOutput</code></li>
<li><em>Visualization example</em>: Below is a demo of how this new feature is intended to be used, an image of diffusion tensor ellipsoids and their associated uncertainty cones.</li>
</ul>
<p style="text-align: center;"><a href="https://user-images.githubusercontent.com/31288525/254747296-09a8674e-bfc0-4b3f-820f-8a1b1ad8c5c9.png"><img alt="DT ellipsoids and its uncertainty" src="https://user-images.githubusercontent.com/31288525/254747296-09a8674e-bfc0-4b3f-820f-8a1b1ad8c5c9.png" width="680"></a></p>
<p>The implementation is almost complete, but as it is a new addition that includes mathematical calculations and for which there is no direct reference for comparison, it requires a more detail review before it can be incorporated.</p>
<p><em>Pull Request:</em></p>
<ul>
<li><strong>DTI uncertainty visualization (Under Review)</strong> <a href="https://github.com/fury-gl/fury/pull/810">fury-gl/fury#810</a></li>
</ul>
<p><strong>Future work:</strong> A tutorial will be made explaining in more detail how to calculate the parameters needed for the uncertainty cones using <strong>dipy</strong> functions, specifically: <a href="https://github.com/dipy/dipy/blob/321e06722ef42b5add3a7f570f6422845177eafa/dipy/denoise/noise_estimate.py#L272">estimate_sigma</a> for the noise variance calculation, <a href="https://github.com/dipy/dipy/blob/321e06722ef42b5add3a7f570f6422845177eafa/dipy/reconst/dti.py#L2112">design_matrix</a> to get the b-matrix, and <a href="https://github.com/dipy/dipy/blob/321e06722ef42b5add3a7f570f6422845177eafa/dipy/reconst/dti.py#L639">tensor_prediction</a> for the signal estimation. Additionally, when ODF implementation is complete, uncertainty for this other reconstruction model is expected to be added, using semitransparent glyphs representing the mean directional information proposed by Tournier [3].</p>
<ul>
<li>
<h3>ODF actor implemented with SDF</h3>
</li>
</ul>
<p>HARDI-based techniques require more images than DTI, however, they model the diffusion directions as probability distribution functions (PDFs), and the fitted values are returned as orientation distribution functions (ODFs). ODFs are more diffusion sensitive than the diffusion tensor and, therefore, can determine the structure of multi-directional voxels very common in the white matter regions of the brain [3]. The current actor to display this kind of glyphs is the <code>odf_slicer</code> which, given an array of spherical harmonics (SH) coefficients renders a grid of ODFs, which are created from a sphere with a specific number of vertices that fit the data.</p>
<p>For the application of this model using the same SDF ray marching techniques, we need the data of the SH coefficients, which are used to calculate the orientation distribution function (ODF) described <a href="https://dipy.org/documentation/1.7.0/theory/sh_basis/">here</a>. Different SH bases can be used, but for this first approach we focus on <code>descoteaux07</code> (as labeled in dipy). After performing the necessary calculations, we obtain an approximate result of the current implementation of FURY, as seen below.</p>
<p style="text-align: center;"><a href="https://user-images.githubusercontent.com/31288525/260909561-fd90033c-018a-465b-bd16-3586bb31ca36.png"><img alt="ODF glyphs comparison using polygons and current ray marching implementation" src="https://user-images.githubusercontent.com/31288525/260909561-fd90033c-018a-465b-bd16-3586bb31ca36.png" width="508"></a></p>
<p>With a first implementation we start to solve some issues related to direction, color, and data handling, to obtain exactly the same results as the current implementation.</p>
<p>Details on the issues:</p>
<ul>
<li><em>The direction and the scaling</em>: When the shape of the ODF is more sphere-like, the size of the glyph is smaller, so for the moment it needs to be adjusted manually, but the idea is to find a relationship between the coefficients and the final object size so it can be automatically scaled. Additionally, as seen in the image, the direction does not match. To fix this, an adjustment in the calculation of the spherical coordinates can be made, or pass the direction information directly.</li>
<li><em>Pass the coefficients data efficiently</em>: I'm currently creating one actor per glyph since I'm using a <em>uniform</em> array to pass the coefficients, but the idea is to pass all the data simultaneously. The first idea is to encode the coefficients data through a texture and retrieve them in the fragment shader.</li>
<li><em>The colormapping and the lighting</em>: As these objects present curvatures with quite a bit of detail in some cases, this requires more specific lighting work, in addition to having now not only one color but a color map. This can also be done with texture, but it is necessary to see in more detail how to adjust the texture to the glyph's shape.</li>
</ul>
<p>More details on current progress can be seen in blogpost of <a href="https://fury.gl/latest/posts/2023/2023-08-16-week-11-tvcastillod.html">week 11</a> and <a href="https://fury.gl/latest/posts/2023/2023-08-24-week-12-tvcastillod.html">week 12</a>.</p>
<p><em>Working branch:</em></p>
<ul>
<li><strong>ODF implementation (Under Development)</strong> <a href="https://github.com/tvcastillod/fury/tree/SH-for-ODF-impl">https://github.com/tvcastillod/fury/tree/SH-for-ODF-impl</a></li>
</ul>
<h2>GSoC Weekly Blogs</h2>
<p>My blog posts can be found on the <a href="https://fury.gl/latest/blog/author/tania-castillo.html">FURY website</a> and the <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/">Python GSoC blog</a>.</p>
<h2>Timeline</h2>
<table>
<tbody>
<tr>
<th>Date</th>
<th>Description</th>
<th>Blog Link</th>
</tr>
</tbody>
<tbody>
<tr>
<td>Week 0<br>
(02-06-2022)</td>
<td>Community Bounding Period</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-06-02-week-0-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-0-2">Python</a></td>
</tr>
<tr>
<td>Week 1<br>
(05-06-2022)</td>
<td>Ellipsoid actor implemented with SDF</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-06-05-week-1-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-1-23">Python</a></td>
</tr>
<tr>
<td>Week 2<br>
(12-06-2022)</td>
<td>Making adjustments to the Ellipsoid Actor</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-06-12-week-2-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-2-18">Python</a></td>
</tr>
<tr>
<td>Week 3<br>
(19-06-2022)</td>
<td>Working on uncertainty and details of the first PR</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-06-19-week-3-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-3-27">Python</a></td>
</tr>
<tr>
<td>Week 4<br>
(27-06-2022)</td>
<td>First draft of the DTI uncertainty visualization</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-06-27-week-4-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-4-24">Python</a></td>
</tr>
<tr>
<td>Week 5<br>
(03-07-2022)</td>
<td>Preparing the data for the Ellipsoid tutorial</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-07-03-week-5-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-5-27">Python</a></td>
</tr>
<tr>
<td>Week 6<br>
(10-07-2022)</td>
<td>First draft of the Ellipsoid tutorial</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-07-10-week-6-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-6-26">Python</a></td>
</tr>
<tr>
<td>Week 7<br>
(17-07-2022)</td>
<td>Adjustments on the Uncertainty Cones visualization</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-07-17-week-7-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-7-26">Python</a></td>
</tr>
<tr>
<td>Week 8<br>
(25-07-2022)</td>
<td>Working on Ellipsoid Tutorial and exploring SH</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-07-25-week-8-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-8-17">Python</a></td>
</tr>
<tr>
<td>Week 9<br>
(31-07-2022)</td>
<td>Tutorial done and polishing DTI uncertainty</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-07-31-week-9-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-9-22">Python</a></td>
</tr>
<tr>
<td>Week 10<br>
(08-08-2022)</td>
<td>Start of SH implementation experiments</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-08-08-week-10-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-10-16">Python</a></td>
</tr>
<tr>
<td>Week 11<br>
(16-08-2022)</td>
<td>Adjusting ODF implementation and looking for solutions on issues found</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-08-16-week-11-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-11-17">Python</a></td>
</tr>
<tr>
<td>Week 12<br>
(24-08-2022)</td>
<td>Experimenting with ODFs implementation</td>
<td><a href="https://fury.gl/latest/posts/2023/2023-08-24-week-12-tvcastillod.html">FURY</a> - <a href="https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-12-9">Python</a></td>
</tr>
</tbody>
</table>
<h3>References</h3>
<p>[1] Basser, P. J. (1997). Quantifying errors in fiber direction and diffusion tensor field maps resulting from MR noise. In 5th Scientific Meeting of the ISMRM (Vol. 1740).<br>
[2] Chang, L. C., Koay, C. G., Pierpaoli, C., & Basser, P. J. (2007). Variance of estimated DTI‐derived parameters via first‐order perturbation methods. Magnetic Resonance in Medicine: An Official Journal of the International Society for Magnetic Resonance in Medicine, 57(1), 141-149.<br>
[3] J-Donald Tournier, Fernando Calamante, David G Gadian, and Alan Connelly. Direct estimation of the fiber orientation density function from diffusion-weighted mri data using spherical deconvolution. Neuroimage, 23(3):1176–1185, 2004.<br>
[4] Gordon Kindlmann. Superquadric tensor glyphs. In Proceedings of the Sixth Joint Eurographics-IEEE TCVG conference on Visualization, pages 147–154, 2004.</p>tvcastillod@unal.edu.co (tvcastillod)Mon, 28 Aug 2023 21:24:09 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/final-report-3/Weekly Check-in #12https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-12-9/<h2><strong>What did I do this week?</strong></h2>
<p>There were different issues I needed to address for the ODF implementation. Even though I could not solve any of them completely, I did check each of the issues and made some progress. All the work in progress is being recorded in the following branch <a href="https://github.com/tvcastillod/fury/tree/SH-for-ODF-impl">SH-for-ODF-impl</a>, which when ready will be associated with a well-structured PR.</p>
<p>First, the scaling. For this part I was suggested to check <em>gfa</em> metric to adjust the scaling depending on the shape of the ODF glyph, i.e., the less the <em>gfa</em> the more sphere-shaped and smaller, so I had to associate a greater scaling for those. However, this did not work very well as I was unable to define an appropriate scale relation that would give an equitable result for each glyph. For this reason, I opted to use <em>peak values </em>which are extracted from the ODFs, setting the scales as 1/peak_value*0.4 and I got a more uniformly sized glyph without the need of setting it manually. That is a temporal solution as I would like to see better why this happens and if possible do the adjustment inside the shader instead of a precalculation. Second, for the direction, I made a small adjustment to the spherical coordinates which affected the direction of the ODF glyph. As you can see below,</p>
<p style="text-align: center;"><img alt="" height="373" src="/media/uploads/acf9b9b5-d7df-4243-9b58-fe7a1d08c445.png" width="391"></p>
<p><br>
All the glyphs are aligned over the <em>y-</em>axis but not over the <em>z-</em>axis, to correct this I precalculated the main direction of each glyph using peaks and passed it to the shader as a <span style="font-family: Courier New,Courier,monospace;">vec3</span>, then used <span style="font-family: Courier New,Courier,monospace;">vec2vecrotmat</span> to align the main axis vector of the ODF to the required direction vector, the only problem with this is that not all the glyps are equally aligned to the axis, i.e., the first 3 glyphs are aligned with the <em>x-</em>axis but the last one is aligned with the y-axis, so the final rotation gives a different result for that one.</p>
<p style="text-align: center;"><img alt="" height="81" src="/media/uploads/c76cb913-b989-4f28-8584-825f936b0391.png" width="393"></p>
<p>As with the first small adjustment of the coordinates the direction was partially correct, I need to double check the <em>theta</em>, <em>phi</em> and <em>r</em> definitions to see if I can get the right direction without the need of the additional data of direction. Also, there might be a way to get the specific rotation angles associated to each individual glyph from the data associated with the ODFs.</p>
<p>Third, passing the coefficients data through textures. I understand better now how to pass textures to the shaders but I still have problems understanding how to retrieve the data inside the shader. I used <a href="https://github.com/fury-gl/fury/blob/master/docs/experimental/viz_shader_texture.py">this</a> base implementation, suggested by one of my mentors, to store the data as a <a href="http://www.khronos.org/opengl/wiki/Cubemap_Texture#:~:text=A%20Cubemap%20Texture%20is%20a,the%20value%20to%20be%20accessed.">texture cubemap</a>, "a texture, where each mipmap level consists of six 2D images which must be square. The 6 images represent the faces of a cube". I had 4x15 coefficients and inside the function, a grid of RGB colors is made so then it can be mapped as a texture. To check if was passing the data correctly, I used the same value .5 for all the textures, so then I could pick a random texel get a specific color (gray), and pass it as <span style="font-family: Courier New,Courier,monospace;">fragOutput0</span> to see if the value was correct. However, it didn't appear to work correctly as I couldn't get the expected color. To get the specific color I used <a href="https://registry.khronos.org/OpenGL-Refpages/gl4/html/texture.xhtml"><span style="font-family: Courier New,Courier,monospace;">texture(sampler, P)</span></a> which samples texels from the texture bound to <em>sampler</em> at texture coordinate <em>P</em>. Now, what I still need to figure out is which should be the corresponding texture coordinate, I have tried with random coordinates, since they are supposed to correspond to a point on the cube and since the information I have encoded in the texture is all the same I assumed that I would get the expected result for any set of values. It might be a problem with the data normalization, or maybe there is something failing on the texture definition. I need to review it in more detail to see where is the problem.</p>
<p>Lastly, the colormapping. For this I created the texture based on a generic colormap from <a href="https://matplotlib.org/stable/tutorials/colors/colormaps.html">matplotlib</a>.</p>
<p style="text-align: center;"><img alt="" height="307" src="/media/uploads/0db5bf26-a41c-40fd-a4ae-8c0e816e1c76.png" width="200"></p>
<p><br>
I was able to give some color to the glyph but it does not match correctly its shape. Some adjustment must be done regarding the texels, as the colormap is mapped on a cube. But I need it to fit the shape of the glyph correctly.</p>
<h2><strong>What is coming up next?</strong></h2>
<p>I will continue to explore more on how to handle textures so I can solve the issues related to the coefficient data and colormapping. Also, take a deeper look at the SH implementation and check what is the information needed to adjust the main direction of the ODF correctly.</p>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>As I mentioned I had some drawbacks in understanding the use of textures and how to retrieve the data inside the shaders. Is a topic that might take some time to manage properly but If I can master it and understand it better, it is a tool that can be useful later. Additionally, there are details of the SH implementation that I still need to understand and explore better in order to make sure I get exactly the same result as the current <span style="font-family: Courier New,Courier,monospace;">odf_slicer</span> implementation.</p>tvcastillod@unal.edu.co (tvcastillod)Thu, 24 Aug 2023 01:54:08 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-12-9/Weekly Check-in #11https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-11-17/<h2><strong>What did I do this week?</strong></h2>
<p>I continued to experiment with the ODF glyph implementation. Thanks to one of my mentors I figured out how to get the missing data corresponding to the SH coefficients <em>a<sub>l</sub></em><sup><em>m</em> </sup>part of the function <em>f(θ, ϕ) </em>described <a href="https://dipy.org/documentation/1.7.0/theory/sh_basis/">here</a>. I also was told to make sure to implement the correct SH basis since there are different definitions from the literature, I have to focus now in the one proposed by Descoteaux, described in <a href="https://onlinelibrary.wiley.com/doi/10.1002/mrm.21277">this paper</a>, which is labeled in <strong>dipy</strong> as <span style="font-family: Courier New,Courier,monospace;">descoteaux07</span>. To do this I had to make a small adjustment to the base implementation that I took as a reference, from which I obtained a first result using SH of order 4.</p>
<p style="text-align: center;"><img alt="" height="367" src="https://user-images.githubusercontent.com/31288525/260909561-fd90033c-018a-465b-bd16-3586bb31ca36.png" width="666"></p>
<p>It appears that the results on the shape are about the same, except for the direction, but there is still work to be done. </p>
<h2><strong>What is coming up next?</strong></h2>
<p>For now there are 3 things I will continue to work on:</p>
<ul>
<li>The color and lighting. As these objects present curvatures with quite a bit of detail in some cases, this is something that requires more specific lighting work, in addition to having now not only one color but a color map.</li>
<li>The scaling. This is something I still don't know how to deal with. I had to adjust it manually for now, but the idea is to find a relationship between the coefficients and the final object size so it can be automatically scaled, or maybe there is a proper way to pre-process this data before passing it to the shaders to get the right result at once.</li>
<li>How to pass the information of the coefficients efficiently. Right now I'm creating one actor per glyph since I'm using a uniform array to pass the coefficients, but the idea is to pass all the data at once. I found several ideas <a href="https://stackoverflow.com/questions/7954927/passing-a-list-of-values-to-fragment-shader">here</a> of how to pass a list of values to the fragment shader directly, I just need to explore deeper on how this can be done on <strong>FURY</strong>, and see which option is most suitable.</li>
</ul>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>All the points mentioned above are things that I tried to fix, however, it is something that I need to look at in much more detail and that I know is going to take me some time to understand and test before I get to the expected result. I hope to get some ideas from my mentors and fellow GSoC contributors on how I can proceed to deal with each of the problems.</p>tvcastillod@unal.edu.co (tvcastillod)Wed, 16 Aug 2023 06:11:52 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-11-17/Weekly Check-in #10https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-10-16/<h2><strong>What did I do this week?</strong></h2>
<p>I started formally working on SH implementation. I was told to start first doing a simple program where I can modify on real time the order <span style="font-family: Courier New,Courier,monospace;">l</span> and degree <span style="font-family: Courier New,Courier,monospace;">m</span>, parameters corresponding to the <a href="https://dipy.org/documentation/1.7.0/theory/sh_basis/">Spherical Harmonics function</a>, based on a <a href="https://github.com/lenixlobo/fury/commit/2b7ce7a71fd422dc5a250d7b49e1eea2db9d3bce">previous work</a>. That is just one part of the final ODF calculation, but here is what a first experimental script looks like.</p>
<p style="text-align: center;"><img alt="" height="288" src="https://user-images.githubusercontent.com/31288525/260910073-10b0edd4-40e3-495c-85ad-79993aef3b19.png" width="581"></p>
<p>I did it in order to make sure it was visually correct and also to understand better how those 2 parameters are related and need to be incorporated into the final calculation. There is one issue at first sight that needs to be addressed, and that is the scaling, since for SH with a degree near 0, the object gets out of bounds.</p>
<h2><strong>What is coming up next?</strong></h2>
<p>I will keep polishing details from my current open PRs, hopefully, I will get another PR merged before the last GSoC week.</p>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>Not sure about how to use the current implementation I have to get similar visualizations made with <span style="font-family: Courier New,Courier,monospace;">odf_slicer</span>, since the parameters that the function receive are different, so I need to take a deeper look and see where it might be the connection or if I should make some adjustments on the parameters.</p>tvcastillod@unal.edu.co (tvcastillod)Tue, 08 Aug 2023 00:31:59 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-10-16/Weekly Check-in #9https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-9-22/<h2><strong>What did I do this week?</strong></h2>
<p>I addressed the comments from the tutorial of <a href="https://github.com/fury-gl/fury/pull/818">PR #818</a> related to how to display specific visualizations I wanted to make. I was suggested to use <span style="font-family: Courier New,Courier,monospace;">ShowManager</span> to handle the zoom of the scene and also to use <span style="font-family: Courier New,Courier,monospace;">GridUI</span> to display several actors at the same time for a visual quality comparison of the tensors. Below are some images generated for the tutorial that is almost done.</p>
<p><img alt="" height="156" src="/media/uploads/0e5d6597-52fd-48f5-aad5-de2383da88dc.png" style="float: left;" width="312"></p>
<p> <img alt="" height="150" src="/media/uploads/1c233c4d-baf2-4471-9466-017c453999aa.png" width="421"></p>
<p><img alt="" height="313" src="/media/uploads/a6665f1f-c0a5-4cda-a46f-5b3ea3dbb821.png" style="float: left;" width="313"> <img alt="" height="313" src="/media/uploads/ceadd952-732e-46fb-9e7f-d3a1509230b1.png" width="313"></p>
<h2><strong>What is coming up next?</strong></h2>
<p>There are some issues with the tests of the uncertainty implementation, specifically a segmentation problem that has to be with the shaders, so I expect to correct the problem by next week.</p>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>I'm still thinking about how to approach the implementation of the spherical harmonics for odf glyphs. Most of the implementations I have found are static so my task would be to try to parametrize the existing functions, so I can pass data from python to the shaders properly so that I can obtain the same result as the current <span style="font-family: Courier New,Courier,monospace;">odf_slicer</span>.</p>tvcastillod@unal.edu.co (tvcastillod)Mon, 31 Jul 2023 22:32:05 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-9-22/Weekly Check-in #8https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-8-17/<h2><strong>What did I do this week?</strong></h2>
<p>I mainly worked on the ellipsoid actor tutorial, as <a href="https://github.com/fury-gl/fury/pull/791">PR #791</a> is finally merged, so I was able to complete the tutorial by adding my implementation. In addition, during the weekly meeting I received a good overview of the next issue I will be working on, that is using raymarching SDFs to display spherical harmonics (SH) for visualizing ODF glyphs for DTI. I got several ideas and resources where I can start experimenting with, such as shadertoy and some base implementations from other FURY contributors. The main drawback when creating these objects is the amount of data required to create them, because depending on the SH order, the number of parameters that the function receives may vary, also unlike the tensors, which are represented only with a 3x3 matrix, here we could have more than 9 values associated with a single glyph, so passing the information from python to the shaders is not so trivial, besides requiring more resources as there is more information that needs to be processed. Some ideas I received were using matrixes instead of vectors, using templating, or even using texture to pass the data. I started to explore these options further, as well as to review in more detail the existing implementations of SH with raymarching, in order to understand them better.</p>
<h2><strong>What is coming up next?</strong></h2>
<p>I currently have two PRs under review, so I will adress the comments I receive and update them accordingly. I also will continue to explore and start working on the implementation of these objects so that I can start making adjustments and further discuss possible improvements to the implementation I will make.</p>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>Not this week.</p>tvcastillod@unal.edu.co (tvcastillod)Tue, 25 Jul 2023 01:55:50 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-8-17/Weekly Check-in #7https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-7-26/<h2><strong>What did I do this week?</strong></h2>
<p>I was told to refactor some parts of the uncertainty PR, since I was relying too much on dipy functions which is not good because it makes maintenance more difficult as dipy requires FURY for some functionalities. So I did some adjustments on the uncertainty function parameters and the corresponding tests, hopefully I managed to get with the most appropiate definition but I need to receive a first feedback to see how much I have to adjust the implementation. As I had to delete some relevant code lines inside the uncertainty calculation which consisted of preprocessing the data in order to define the necessary variables for the uncertainty formula, I was also suggested to make a tutorial of this new feature, so I can explain in detail how to obtain and adjust the necessary information, before passing it to the actor, and in general how and what is the purpose of this new function.</p>
<p>I also continued working on the ellipsoid tutorial, which I hope to finish this week so that I can ask for a first revision.</p>
<h2><strong>What is coming up next?</strong></h2>
<p>I will finish defining some details of the tutorial so that it is ready for review, and now I will start working on the tutorial related to the uncertainty, while I receive feedback on the other PRs. Also, as preparation for the next step I will start exploring on how to adress visualization of spherical harmonics for ODF glyphs visualization, I found that a previous GSoC participant at FURY started working on that and also did several work with raymarching and SDF (<a href="https://fury.gl/latest/posts/2020/2020-08-24-final-work-lenix.html">here</a> is a summary of their work), so I will take a deeper look on that to see if I can get something useful I can start with.</p>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>Not this week, but I foresee some problems with the uncertainty PR, we will see how it goes.</p>tvcastillod@unal.edu.co (tvcastillod)Mon, 17 Jul 2023 18:33:42 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-7-26/Weekly Check-in #6https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-6-26/<h2><strong>What did I do this week?</strong></h2>
<p><a href="https://github.com/fury-gl/fury/pull/818">#PR 818: Tutorial on using ellipsoid actor to visualize tensor ellipsoids for DTI</a></p>
<p>I created the PR for the tutorial that will show the use that can be made of the ellipsoid actor in the visualization of diffusion tensor ellipsoids. It is still in its most basic stage, but the structure that I have thought of for now consists of: displaying a slice using <span style="font-family: Courier New,Courier,monospace;">tensor_slicer</span> with spheres of 100, 200, and 724 vertices, and using <span style="font-family: Courier New,Courier,monospace;">ellipsoid</span> actor, and show a comparison of the visual quality of the tensor ellipsoids. Then, display a ROI using both actors and a whole brain using the ellipsoid actor, to show that this new actor gives the possibility to display more data.</p>
<p>I also submitted the <a href="https://github.com/fury-gl/fury/pull/810">uncertainty PR</a> for review, in order to start making the necessary corrections.</p>
<h2><strong>What is coming up next?</strong></h2>
<p>I need <a href="https://github.com/fury-gl/fury/pull/791">#PR 791</a> to be merged first, but meanwhile, I will start working on the explanation of the tutorial, since I already have the code structure and the idea of what I want to illustrate. I will discuss further work with my mentors at the upcoming meeting, so I can organize myself better and plan how I'm going to address the pending parts of my project.</p>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>I found no major difficulties this week.</p>tvcastillod@unal.edu.co (tvcastillod)Mon, 10 Jul 2023 17:56:40 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-6-26/Weekly Check-in #5https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-5-27/<h2><strong>What did I do this week?</strong></h2>
<p>During the weekly meeting with my mentors, there was a small discussion over the naming of the actor and its usage. On the one hand, although the purpose of the actor is to visualize diffusion tensor ellipsoids, the idea is that it can also be used for any other type of visualization that requires the use of ellipsoids, so in the end, we decided to keep the name ellipsoid as it is more generic. On the other hand, as there is already an actor made for the purpose of tensor visualization, namely <a href="https://github.com/fury-gl/fury/blob/e595bad0246899d58d24121dcc291eb050721f9f/fury/actor.py#L1172"><span style="font-family: Courier New,Courier,monospace;">tensor_slicer</span></a>, it might not be obvious how and why one would use this new ellipsoid actor for this purpose, thus it was proposed to make a tutorial that can clarify this. The main difference between both actors relies on the quality and the amount of data that can be displayed, so the idea is to show the difference between both alternatives so the user can choose which one to use depending on their needs. To prepare the tutorial the first step was to <a href="https://github.com/fury-gl/fury-data/pull/12">add the data</a> I will use on <a href="https://github.com/fury-gl/fury-data">fury-data</a> so I can then fetch and load the datasets I need to work on the tutorial.</p>
<h2><strong>What is coming up next?</strong></h2>
<p>I need <a href="https://github.com/fury-gl/fury/pull/791">#PR 791</a> to be reviewed by my GSoC fellows at FURY, so I will address their comments, and additionally make adjustments on <a href="https://github.com/fury-gl/fury/pull/810">#PR 810</a> based on the feedback I receive. I will also start working on the tutorial, the idea is to show the use that can be made of the <span style="font-family: Courier New,Courier,monospace;">ellipsoid</span> actor in the visualization of diffusion tensor ellipsoids, compared to the <span style="font-family: Courier New,Courier,monospace;">tensor_slicer</span> actor. I plan to create a WIP PR to start getting feedback on the general structure of the tutorial and the way everything will be explained.</p>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>I did not encounter any obstacles this week.</p>tvcastillod@unal.edu.co (tvcastillod)Mon, 03 Jul 2023 05:56:57 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-5-27/Weekly Check-in #4https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-4-24/<h2><strong>What did I do this week?</strong></h2>
<p><a href="https://github.com/fury-gl/fury/pull/810">#PR 810: DTI uncertainty visualization</a></p>
<p>I made a second PR with the implementation of DTI uncertainty calculation and visualization. I had to use some dipy functions, especifically: <span style="font-family: Courier New,Courier,monospace;"><a href="https://dipy.org/documentation/1.4.1./reference/dipy.denoise/#estimate-sigma">estimate_sigma</a></span> for the noise variance calculation, <span style="font-family: Courier New,Courier,monospace;"><a href="https://dipy.org/documentation/1.4.0./reference/dipy.reconst/#design-matrix">design_matrix</a></span> to get the b-matrix, and <span style="font-family: Courier New,Courier,monospace;"><a href="https://dipy.org/documentation/1.4.0./reference/dipy.reconst/#tensor-prediction">tensor_prediction</a></span> for the signal estimation. The details of this calculations can be found <a href="https://onlinelibrary.wiley.com/doi/full/10.1002/mrm.21111">here</a>.</p>
<h2><strong>What is coming up next?</strong></h2>
<p>I will continue working on the uncertainty PR which is still in its early stage, I'm going to make a couple of adjustments to the description of the parameters and the actor, and keep working on based on the feedback I receive. There are also minor details to be discussed with my mentors about the first PR, which I hope to finish refining.</p>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>It took me a while to make the PR because I had some problems with the uncertainty function definition. I tried to use the least amount of parameters for the function, since with data, bvals and bvecs it is possible to obtain the rest of the parameters needed to generate the cones, which led me to readjust some calculations from the base implementation I had, to keep everything working correctly.</p>tvcastillod@unal.edu.co (tvcastillod)Tue, 27 Jun 2023 21:41:26 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-4-24/Weekly Check-in #3https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-3-27/<h2><strong>What did I do this week?</strong></h2>
<p>I made some adjustments to the ellipsoid actor definition, now called tensor. This was something discussed in the weekly meeting as the coming changes are related to this actor, the idea now is to have a tensor actor that allows choosing between displaying the tensor ellipsoids or the uncertainty cones (later on). I also worked on the uncertainty calculation, and the cone SDF for the visualization, so I plan to do a WIP PR next to start getting feedback on this new addition.</p>
<h2><strong>What is coming up next?</strong></h2>
<p>As for uncertainty calculation, other data is needed such as the noise variance and the design matrix (check <a href="https://onlinelibrary.wiley.com/doi/full/10.1002/mrm.21111">this</a> article for more details), I need to identify which should be the parameters for the function definition. I also have to work on the documentation, so the function and its purpose are clear. I plan to make the final adjustments related to the uncertainty so that the next PR is ready for submission this week. I also expect to make the final changes to the first PR so that it can be merged soon.</p>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>Not this week, I will wait for feedback to see if there is anything I need to review or correct.</p>tvcastillod@unal.edu.co (tvcastillod)Mon, 19 Jun 2023 22:02:24 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-3-27/Weekly Check-in #2https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-2-18/<h2><strong>What did I do this week?</strong></h2>
<p>I made some minor adjustments to the last PR I submit. Last time it was a draft since I was waiting for the weekly meeting to know how to proceed, but now is ready. I am waiting for the review so I can make the necessary corrections and adjustments to merge this first PR soon.</p>
<h2><strong>What is coming up next?</strong></h2>
<p>As I receive feedback, I will continue to work on the <a href="https://github.com/fury-gl/fury/pull/791">PR #791</a> and make adjustments and changes as needed. That said, I will start working on another part of the project, which is the visualization of uncertainty. Without going into details (for now) what I have to do is:</p>
<ul>
<li>Create a double_cone or dti_uncertainty actor. I’m going to work on the double cone made also with raymarching and SDF, since the implementation is pretty much the same as the ellipsoid I already have.</li>
<li>Make a function that returns the level of the uncertainty given by the angle of the uncertainty cone we want to visualize. For this I need to double-check the maths behind the uncertainty calculation to make sure I’m getting the right results.</li>
</ul>
<h2><strong>Did I get stuck anywhere?</strong></h2>
<p>Not exactly, but one of the things that were mentioned in the last meeting is that we should try to simplify the shader code as much as we can, that is, to break down the entire implementation into simple and easy-to-understand lines of code, which also allows the definition of functions that can be reused later on. I need to keep working on this, so I can make my code even more readable and fit the new shader structure.</p>tvcastillod@unal.edu.co (tvcastillod)Mon, 12 Jun 2023 18:06:35 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-2-18/Weekly Check-in #1https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-1-23/<h2 style="text-align: justify;"><strong>What did I do this week?</strong></h2>
<div style="text-align: justify;"><a href="http://github.com/fury-gl/fury/pull/791">PR #791: Ellipsoid actor implemented with SDF</a></div>
<div style="text-align: justify;"> </div>
<div style="text-align: justify;">I made a first PR with the implementation of the ellipsoid actor defined with an SDF using raymarching. The current <span style="font-family: Courier New,Courier,monospace;"><a href="https://github.com/fury-gl/fury/blob/c2e5151e5f0d676501c0aee9f476d9d292cadc61/fury/actor.py#L3537">sdf</a></span> actor allows the creation of ellipsoids, but it lacks control over their shape, and the displayed direction does not match the intended orientation. For this reason, a new actor just focused on ellipsoids was made, this one is defined by its axes (3x3 orthogonal matrix) and their corresponding lengths (3x1 vector), along with other attributes like color, opacity and scale. The goal is to make an implementation that allows displaying a large amount of data, with good visual quality, and without compromising performance. I'm still working on this but here is a first glance of how it looks like:</div>
<div style="text-align: justify;">
<p style="text-align: center;"><img alt="" height="226" src="https://drive.google.com/uc?id=176cT5zZSPdss7MD2ak5Zlk0cU5KNlmSl" width="337"></p>
<div>This will be used later to create the tensor ellipsoids used on <span style="font-family: Courier New,Courier,monospace;"><a href="https://github.com/fury-gl/fury/blob/c2e5151e5f0d676501c0aee9f476d9d292cadc61/fury/actor.py#L1172">tensor_slicer</a></span>.</div>
</div>
<h2 style="text-align: justify;"><strong>What is coming up next?</strong></h2>
<div style="text-align: justify;">I need to talk to my mentors first but the idea is to start making improvements on SDF definition and raymarching algorithm, I have already started looking for information about how I can do it, and if I get good ideas, I will compare if there is an improvement in performance respect to the implementation I have right now. I also need to keep working of tests, the most common ways of doing it is to check the number of objects and colors displayed, but I would like to test other things related to performance.</div>
<h2 style="text-align: justify;"><strong>Did I get stuck anywhere?</strong></h2>
<p style="text-align: justify;">Not yet, I need to get feedback first to see if there is anything I need to review or correct.</p>tvcastillod@unal.edu.co (tvcastillod)Mon, 05 Jun 2023 17:21:34 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-1-23/Weekly Check-in #0https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-0-2/<p style="text-align: justify;">Hello everyone, my name is Tania Castillo, I am close to finishing my degree in Computer Science and I think this is a great opportunity to put my learning and skills into practice. I will be working with FURY on improving the visualization of DTI tensors and HARDI ODFs glyphs by using well-known techniques in computer graphics.</p>
<h2 style="text-align: justify;"><strong>What did I do this week?</strong></h2>
<p style="text-align: justify;">During the community bonding period, I had the opportunity to get to know better GSoC mentors and former contributors. I also had the first meeting with FURY mentors where I got to learn more about the dynamic of the program, important things to keep in mind while coding, and suggestions when making the PRs. We also receive some details on how to work with shaders which is something I have to take into account since I will use them to develop part of the project. In addition, I’ve been working on the first part of the project which consists of the creation of tensor ellipsoids using the raymarching technique and SDFs.</p>
<h2 style="text-align: justify;"><strong>What is coming up next?</strong></h2>
<p style="text-align: justify;">Since the advances I managed to make are in their most basic stage, I will be working this week on making changes and adjusting details for the implementation to follow fury guidelines. In this way, I plan to submit my first PR for the project to start getting feedback and making improvements. I will also start working on the first tests for the ellipsoid actor I’m working on.</p>
<h2 style="text-align: justify;"><strong>Did I get stuck anywhere?</strong></h2>
<p style="text-align: justify;">For now, everything is going well, although I know I will probably run into some problems when reviewing and adjusting my code. We will see later this week.</p>tvcastillod@unal.edu.co (tvcastillod)Fri, 02 Jun 2023 04:25:22 +0000https://blogs.python-gsoc.org/en/tvcastillods-blog/weekly-check-in-0-2/