Hello everyone, it's time for another weekly blogpost! This week, I will talk about how you should watch your expectations when working with any project.

This Last Week's Effort

As I supposedly managed to make the texture allocation part working, this last week's goal was to render something to a FBO. Well, I could make textures work, but what I wasn't expecting and later realised, was that the FBO setup not working. Below I will describe where I got stuck.

Where the Problem Was

After getting the textures setup right, I was ready to render some color to the FBO. Well, I was, because I didn't expect I would have another problem, this time, with the FBO setup. As described in my week 1 blogpost, a FBO needs some requirements to work. My current problem relies on the FBO method FBO.SetContext(), that for some reason is not being able to generate the FBO. Below, how the method is currently operating:

Apparently, the method is stuck before the this->CreateFBO(), that can be checked when we call FBO.GetFBOIndex(), that returns a 0 value, meaning the FBO was not generated by the glGenFramebuffers() function, that is inside the GetContext() method.

This Week's Goals

As I got stuck again with this simple step, talking with my mentors we concluded that a plan B is needed for my GSoC participation as my current project is not having much progress. This plan B that I am gonna start working on this week involves working on FURY Speed, a FURY addon that aims to develop optimized functions and algorithms to help speed up graphical applications. The suggestion was to work on a PR I submitted months ago, #783, in a way to integrate that into FURY Speed. Also, I plan to keep working on my current project to find the solution I will need to make the FBO usage work.

Let's get to work!

Hello everybody, welcome to the week 2 of this project! I must admit I thought this would be simpler than it is currently being, but I forgot that when it comes to dealing with computer graphics' applications, things never are. Below, some updates on what I have been up to for this past week. 

This Last Week's Effort

Last week, I was facing some issues with a VTK feature essential so I could move forward with my project: Framebuffer Objects. As described in my last blogpost, for some reason the 2D allocation methods for it weren't working. In a meeting with my mentors, while we were discussing and searching through VTK's FramebufferObject and TextureObject documentation, and the code itself for the problem, one TextureObject method caught my attention: vtkTextureObject.SetContext().

Where the Problems Were

My last week's code was:

color_texture = vtk.vtkTextureObject() # color texture declaration
color_texture.Bind() # binding of the texture for operations

color_texture.SetDataType(vtk.VTK_UNSIGNED_CHAR) # setting the datatype for unsigned char
color_texture.SetInternalFormat(vtk.VTK_RGBA) # setting the format as RGBA
color_texture.SetFormat(vtk.VTK_RGBA)
color_texture.SetMinificationFilter(0) # setting the minfilter as linear
color_texture.SetMagnificationFilter(0) # setting the magfilter as linear

color_texture.Allocate2D(width, height, 4, vtk.VTK_UNSIGNED_CHAR) # here is where the code stops

But it turns out that to allocate the FBO's textures, of type vtkTextureObject, you need to also set the context where the texture object will be present, so it lacked the line:

color_texture.SetContext(manager.window) # set the context where the texture object will be present

And with that line added after Bind():

color_texture = vtk.vtkTextureObject()
color_texture.Bind()

color_texture.SetContext(manager.window) # set the context where the texture object will be present

color_texture.SetDataType(vtk.VTK_UNSIGNED_CHAR)
color_texture.SetInternalFormat(vtk.VTK_RGB)
color_texture.SetFormat(vtk.VTK_RGB)
color_texture.SetMinificationFilter(0)
color_texture.SetMagnificationFilter(0)

The code worked fine. But as my last blogpost showed, Allocate3D() method worked just fine without a (visible) problem, why is that? Well, in fact, it didn't work. If we check the code for the Allocate2D and Allocate3D, one difference can be spotted.

While in Allocate2D there is an "assert(this->Context);", in Allocate3D the assertion is translated into:

if(this->Context==nullptr)
{
  vtkErrorMacro("No context specified. Cannot create texture.");
  return false;
}

This slight difference is significant: while in Allocate2D the program immediatly fails, in Allocate3D the function is simply returned false, with its error pushed to vtkErrorMacro. I could have realised that earlier if I were using vtkErrorMacro, but this contrastant implementation made it harder for me and my mentors to realise what was happening.

This Week's Goals

After making that work, this week's goal is to render something to the Framebuffer Object, now that is working. To do that, first I will need to do some offscreen rendering to it, and afterwards render what it was drawn to its color attachment, the Texture Object I was struggling to make work, into the screen, drawing its texture to a billboard. Also, I plan to start using vtkErrorMacro, as it seems like the main error interface when working with VTK, and that may make my life easier.

See you next week!

This Past Week

As mentioned in the last week's blogpost, the goal for that week was to investigate VTK's Framebuffer Object framework. An update on that is that indeed, VTK has one more low-level working FBO class that can be used inside FURY, however, they come with some issues that I will explain further below.

My Current Problems

The problems I am having with these FBO implementations are first something related to how an FBO works, and second related to how VTK works. In OpenGL, a custom user's FBO needs some things to be complete (usable):

1. At least one buffer should be attached. This buffer can be the color, depth or stencil buffer.
2. If no color buffer will be attached then OpenGL needs to be warned no draw or read operations will be done to that buffer. Otherwise, there should be at least one color attachment.
3. All attachments should have their memory allocated.
4. Each buffer should have the same number of samples.

My first problem relies on the third requirement. VTK's implementation of FBO requires a vtkTextureObject as a texture attachment. I figured how to work with this class, however, I cannot allocate memory for it, as its methods for it, Allocate2D, Create2D and Create2DFromRaw does not seem to work. Every time I try to use them, my program stops with no error message nor nothing. For anyone interested in what is happening exactly, below is how I my tests are implemented:

color_texture = vtk.vtkTextureObject() # color texture declaration
color_texture.Bind() # binding of the texture for operations
color_texture.SetDataType(vtk.VTK_UNSIGNED_CHAR) # setting the datatype for unsigned char
color_texture.SetInternalFormat(vtk.VTK_RGBA) # setting the format as RGBA
color_texture.SetFormat(vtk.VTK_RGBA)
color_texture.SetMinificationFilter(0) # setting the minfilter as linear
color_texture.SetMagnificationFilter(0) # setting the magfilter as linear

color_texture.Allocate2D(width, height, 4, vtk.VTK_UNSIGNED_CHAR) # here is where the code stops

In contrast, for some reason, the methods for 3D textures, Allocate3D works just fine.I could use it as a workaround, allocating memory for a width x height x 1 texture (equivalent to a 2D texture) but I do not wish to, as this just does not make sense.

My second problem relies on VTK. As VTK is a library that encapsulates some OpenGL functions in more palatable forms, it comes with some costs. Working with FBOs is a more low-level work, that requires strict control of some OpenGL states and specific functions that would be simpler if it was the main API here. However, some of this states and functions are all spread and implicit through VTK's complex classes and methods, which doubles the time expended to make some otherwise simple instructions, as I first need to dig in lines and lines of VTK's documentation, and worse, the code itself.

What About Next Week?

For this next week, I plan to investigate further on why the first problem is happening. If that is accomplished, then things will be more simple, as I will be a lot easier for my project as I will finally be able to implement the more pythonic functions I will need to finally render some kernel distributions onto my screen.

Wish me luck!

So It Begins...

Hello everyone, welcome to the beggining of my journey through GSoC 2023! I would like to thank everyone involved for the opportunity provided, it is an honour to be working side by side with professionals and so many experienced people from around the world.

The Community Bonding Period

During my community bonding period, I had the opportunity to meet my mentors ans some people from the FURY team. It was a great time to learn about community guidelines and everything I will need to work with them during this summer.

The Project's Goal

For some reason I am having trouble with uploading my proposal, so I will introduce my goals. Briefly explaining this project, I plan to implement a real-time Kernel Density Estimation shader inside FURY library, based on Filipi Nascimento's WebGL implementation. KDE, or Kernel Density Estimation, is a visualization technique that provides a good macro visualization of large and complex data sets, like point clouds, well summarizing their spatial distribution in smooth areas. I really think FURY will benefit from this as a scientific library, knowing it is a computer graphics library that originated in 2018 based on the Visual Toolkit API (VTK), and has been improving since then.  

This Week's Goal

For all of this to work, the project needs one component working: the KDE framebuffer. As this Khronos wiki page well explains:

"A Framebuffer is a collection of buffers that can be used as the destination for rendering. OpenGL has two kinds of framebuffers: the Default Framebuffer, which is provided by the OpenGL Context; and user-created framebuffers called Framebuffer Objects (FBOs). The buffers for default framebuffers are part of the context and usually represent a window or display device. The buffers for FBOs reference images from either Textures or Renderbuffers; they are never directly visible."

Which means that a framebuffer is an object that stores data related to a frame. So the goal for this week is to investigate whether VTK, the API which FURY is written on, has a framebuffer object interface, and if it has, to understand how it works and how to use it for the project. 

Let's get to work!