Updates:

• I tried to optimize code, and optimize as much as i could using CPU processing, however for further optimization and particle generation I experimented with GPU programming, however I feel as that is outside the scope of what I want to do with this project.
• Added a GUI so that you can control variables like gravity, target density, etc. Added mouseLock so that if you press M it lock the mouse on the current camera orientation.
• Also fixed up broken physics code and refactored tiny bits of code for optimization, honestly it didnt have much of a difference

Changelog

• fixed interactibility issues
• added additional interactibility
• user interactibility
• created interaction.h file
• finalized values, fixed up broken physics code

Updates:

• Fixed broken code which was the Verlet integration function. Basically I was updated position and velocity before i even computed the fluid forces, so everything was delayed by a frame. So i had to move updateFluid down and remove Verlet integration and just hardcode updated velocity and position.
• I also fixed my value problem, due to the wrong order for computing forces, the delay and lag resulted in current particles being affect by previous forces, which resulted in the particles phasing through each other under high pressure. After the fix they now dont phase and overlap each other.

Next Steps:

1. Optimize code so that it can run above 50,000 particles (currently it runs around 15,000 decently smooth. The number mentioned in previous devlog was incorrect. I will do this by coding directly to the GPU instead of the cpu for faster calculations.
2. Add interactive features, and rigid bodies to see the fluid behaviour against colliding bodies

Changelog

• finalized values, fixed up broken physics code
• refactored and tuned values

Updates:

• Added multithreading so that it can compute in parrallel, and also updated how its compiled by using -O2 for it to more efficiently and hastly compute vectors and arrays.
• Optimized code by removing unesscary code that ran every frame such as drawParticle as a funciton, etc.
• It can handle around 70,000 particles but only for a short while before my computer starts burning up
• Added color interpolation for velcity, and most of the time was to tune the properties (restDensity, viscosity, stiffness, etc) Using claude I figured that we could just normalize it and I kept experimenting until i found decent values that worked.
• Fixed the values so that it would simulate fluid behaviour properly, its still really broken, but I got it to work somewhat.

Changelog

• refactoring and tuning code
• testing
• fixed all values and tuned the fluid behaviour
• refactoring code for visualization

Updates:

• Optimized code so that it can handle thousands of particles using Spatial Hashing Grid
• testes and fine tuned the values of the fluid properties (density, viscosity, stiffness, etc)
• Added the spatialGrid class that basically only compares to neighboring particles to optimize for O(n). Previously it was O(n^2) because there could be a possibly that every other particle is in the influence of this particle, so it would check every particle.

Next Steps:

1. Optimize it further so that it can run much more efficently and with even more particles
2. Implement multi-threading so that I can calculate in parallel for faster computation and thus more particles can be simulated without crashing every second.

Changelog

• tuning restDensity and other properties
• refactored and testing code

Updates:

• Implemented SPH (Smoothed Particle Hydrodynamics) which basically predicts behavior of fluid flow over time.

• SPH help to discretize the continuity of fluids by sampling the values (density, velocity, etc) of a certain region into one particle location

• Kernel Function: a smooth bell curve that shows how a physical property (like mass or velocity) is distributed in the particle’s region. This helps to keep the continuity of fluids without storing everything

• Different types of Kernel for different fluid quantities (density, viscosity, pressure)

1. Poly6 for density
2. Spiky for pressure
3. Laplacian for viscosity

Then we can compute for density, pressure, and finally the total force on the particle and add that value to the particles acceleration. These key features help to simulate fluids more effectively and realistically without needing to store millions of datapoints.

Updates:

• Added 3D particles using a previous function I made for particle simulation.
• Implemented zRange for grid so that it can make a 3D grid of particles
• Fixed velocity verlet integration and added additional functions for 3D particle from previous project

Next Steps:

• Learn about properties and characteristics of fluid and the governing laws behind them, and a possible implementation in code.
• Going to add viscosity, density, cohesion, etc.

Created a build file for all operating systems with the help of Claude.

Updates:

• implemented drawing multiple particles as a grid
• implemented gravity as acceleration
• added a boundary box with boundary collision
• implemented particle collision
• implemented camera lock where you have your camera permantly set

Next Steps:

• I think I will aim to start from the ground up when building the fluid simulation, going from the quantum state all the way to the normal fluid simulation
• Implement a quantum system

Added Camera System from my previous project
Created a draw particle/circle function
Initialized GLFW window for rendering
Setup OpenGL
Created Particle Class for fluid simulation

Updates:

• Fixed verlet integration to update based on gravitational acceleration rather than each particles acceleration
• Added gravitational acceleration to the bottom center of the boundary sphere
• Updated the boundary visualisation into lines instead of dots
• Fixed up code so that it would work alongside the gravity acceleration

Updates:

• Added verlet integration for smoother and stable positional updates. Also cleaned up code.
• Added Clamping to the camera pitch to make sure we dont end up in some weird camera position, and to make it a orbital camera instead of free moving.

P.S. Dont know how I have 1 hour on this?

Updates:

• Implemented Quaternion Class and Camera class for a fully functional camera system. Prevents Gimbal Lock and faster computation and same rotation irrelevant of what comes first or next in multiplication.
• I had learned about Quaternions in my previous project when building a software rasterizer I just had to understand and add the neccessary function to implement in C++.

Next Steps:

• Realistic collision (Elastic and Inelastic)
• Different effect depending on collision of different masses
• Introduce friction, air drag, and other natural variables

Updates:

• Cleaned up Code and added structured comments to each part for clean readability.
• Updated readme file
• added test particle for future testing.
• Added lighting to the simulation for more realistic affect

Updates:

(Inspired by Michael Richardson)

• Added 3D particle collision by comparing the current iteration particle to the next iteration (i + 1), and seeing if there distances (positional) were less than there radius + and other radius (if they are not into each other)
• Created a Sphere Boundary for better visual effects
• Implemented energy loss (damping) for each collision
• Spawned particles from a bit above the center of the sphere boundary

Current Bugs:

1. The spawned particles are initially being stuck and frozen on the starting position, and I dont know why

Next Steps:

• Optimize particle collision algorithm (currently need 0(n^2) because it uses two for loops to check for collisions
• Add better gravity simulation and other natural variables affect in simulation

Updates:

• Added 3D particles and camera
• Learned about OpenGL 3D rendering pipeline
• Create Particle3D class for drawing 3D spheres, and boundary collision
• Added Lighting and Visible boundary box
• Also implemented gravity mode and I can control the gravity acceleration
• Control over the angle of particle movement (phi and theta)

Next Steps:

• I want to be able to now spawn particles at one point and add particle collision and just simulate the effect of that. I will also need to optimize the code so that it can handle hundreds of particles

Added gravity acceleration. The particle is now filled and is bounded by the screen size, moreover added mouse mode where the particle follows the mouse. The particle is attracter to the center of the screen.

As this was my first time using C++ or any language that goes directly for compiling, I had to learn about the tasks.json files, and C++ syntax and how everything works (classes, variables, pointers, etc). And this was my first time using OpenGL, I had to set it up and other libraries and dependencies. After I got the hang of everything, I made a triangle, and then tried to implement my own particle class. Eventually I drew a circle with velocity.

Updates:

• Made code more readable and seperated into folders and specific classes for each step in the pipeline.
• Changed model form Googles Ai to GMeta Llama for free use, however the model is much slower

Future Steps:

• I will be getting my Raspberry Pi 5 pretty soon so I will load in a LLM into it for local offline use, no need to use API Keys or other cloud based AI’s

Updates:

• Added speech recognition
• Made sure the output is formatted text
• Cleaned up code and fixed errors
• Used Claude for converting JSON special things (idk what they are called)

Inspiration:
https://github.com/GauravSingh9356/J.A.R.V.I.S?tab=readme-ov-file

Future steps:

• Create a GUI for my jarvis
• Connect it to a raspberry pi 5 so that it can run locally instead of on the cloud
• make it talk back to me (text to speech)

P.S. It got my name WRONG (its Jahaan)

Updates

• Initialized api_key from HackClub’s free AI website
• Created a shell script for a custom command (hey-jarvis) to run the AI model from anywhere in the terminal

Future Steps:

• Add speech and face recognition
• Command 3D models through specific hand gestures
• Create a GUI for jarvis just like Siri

After hours of just debugging and even creating a shell script and index.html for browser support so that my java application can run in the browser, it didn’t work. I now reverted back to my old code, removed the web folder that contained index.html and the shell script for recompiling. The problem is that since java applets are not supported by browsers, my java application cannot run in the browser. It eevn worked for a bit but stopped after like 5 seconds because CheerpJ (the java virtual machine that compiles my java code into WebAssembly and JavaScript) doesn’t support multiple threads, then i tried to fix that, but it lead to a another issue, and it kept happening, so i reverted back to my old code

Updates: Learning to make the java program useable in the browser, created an html and Javascript file along with using CheerpJ to be able to run Java programs in the web. It’s not working though as there is some problem with loading files from my resources.

Added new resources, and textures, the default will be a head model with skin texture.

Here is the new model, (just wanted to show this, no real change to the code has been made)

Implemented Textures onto any model, need to fix the perspective texture issue in the future.

TWO HOURS FOR DEBUGGING BECAUSE MY OBJ FILE WAS NOT IN THE CORRECT WINDING ORDER!!!!!!

Implemented camera rotation with quaternions. Added methods in my quaternion class, and camera class that integrate quaternion movement and rotation. Updated rasterizer class to handle the camera quaternion system.

Updates:

• Added quaternion class for camera rotation

After making my camera rotation code through Euler Angles, I realized that real modeling engines and game engines don’t use Euler Angles fully as they have many disadvantages such as, computational heavy, gimbal, lock, etc. With research, I came across Quaternions, which are basically a 4-dimensional numerical system* (imp), with a real part (a) and an imaginary part (bi + cj + dk).

To explain briefly, just like how imaginary number i extends the numberline and shows rotation of a vector around an axis* (imp), quaternions entend that concept to bring that in 3d rotations (3-imaginary components which all represent orientation/position.) Just like rotation for the complex plane where we use exponents for faster and efficient math, (e^ix = cosx + isinx), we can extend this by taking the 3 components to represent 3D space, thus a quaternion rotation can be represent as: cos(x/2) + sin(x/2)(xi + yj + zk), where (xi + yj + zk) is one of the vector which we want to rotate around and cos(x/2) the amount we want to rotate. Multiplying two unit quaternions (like basis vectors) results in rotation from A to B, or B to A depending on order of multiplication. This can be calculated through cross product which gives us the perpendicular vector to the plane formed by A and B which is the same as axis, and the rotation amount can calculated as dot product (geometrically) between A and B. After knowing the point in quaternion number basis, we have to convert it into our 3D world, which is done through a change of basis, which I am still wrapping my head around.

P.S. the x/2 found in the rotation quaternion is there because due to the rules that define quaternions, after multiplying you find out that the end result is actually 2 times the rotation you wanted, thus the divide by 2.

Update:

• Cleaned up my graphics pipeline
• added matrix methods to optimize pipeline
• added all transform inside NDC

Update:

• Cleaned code, by added methods/fucntions for conversion form NDC (normalized device coordinates ( -1 to 1)) into screen coordinates
• Added Camera class to handle camera movement and camera rotation, instead of only being able to rotate the model
• Seperated Vector3D and Vector4D into seperate classes, and added a couple of methods in both and Matrix classes

In this devlog, from my experience with all the OOP I learned along the way, I cleaned and fixed my code up so that its much better formatted and so that not everything is in the Rasterizer file. I also tried to implement camera rotation instead of just having model rotation, still currently doing that, but it different than rotating the mesh as that just a transformation, while moving the camera means to transform the model in the cameras basis/ coordinate system. Which is called Inverse Transformations, will learn that and keep updating. PEACE!!

Update:

• Cleaned up code by adding render function
• Added and Learned about Depth Buffering
  • Create a class for DepthBuffer that creates the buffer
  • Implemented DepthBuffer into my LineDrawer and Rasterizer files
• Also added clipping for near and far plane

In this devlog, I learned and added Depth Buffering. Depth Buffering otherwise known as Z-buffering removes any problem of rendering overlapping pixel, for example problems such as rendering farther objects on top of closer ones. It does this by comparing each pixel for z and draws the z that is closer (less) to the camera.

Updated:

• Model Perspective
• Near Clipping Plane
• ClockWise triangle orientation

I finally fixed my perspective problem with my models, it was that for some weird reasons at particular rotations or orientations they would be way out of perspective. The issue of this problem was that i was calculating for Counter-Clockwise triangles, while I made my mesh with Clockwise orientation Meaning that when i calculate the cross-product what was suppose to be negative was actually positive adn vice-versa. Also added clipping by just saying that if the one of the points in the triangle are behind near plane, then dont include, I will soon switch to proper clipping which will calculate for each point instead.

P.S. Debugging this took more than 80% of the time, because I didn’t know why it wasnt working, and then found out that its because my thing had wrong orientation

I made a yml file for my github workflow to automatically, convert the dmg file I made into a EXE file and bundle JRE file, with the help of Claude. I then pushed it onto my repo and updated my release. The demo should be working now, with a runnable app with exe file for Windows.

Oh boy, this was really rough, I spent like 2-3 hours just debugging. I ended up deleting my old repo and creating a new one just to clean and start anew with my new profound knowledge in using git and GitHub.

But i still messed up, as when i was creating my dmg file for my software rasterizer it just wouldn’t work. And when it worked, i had to make it so that the app could be received from every OS. I’m still in the middle of that, but I hope I can ship this tommorow and they can approve, so I can actually start adding features.

After procastinating not using git, I spend a lot of time learning to use git on my laptop and getting used to pushing commits. Had a lot of trouble, but eventually got it to work.

I fixed up some file structure and then updated the ReadMe file to show my work properly, and be allow other people to test my program, and demo it.

I also fixed up a bit of the code, as it was messy and just overall cleaned up my entire project

Created a Basic Software Rasterizer in Java:
The core of any graphic engine, or any graphics in general is the Graphics Pipeline:

1. OBJ Loader and Model parser (Convert model into smaller triangles)
   Acquire the world coordinates/vertices (x,y,z) of the model. Given the coordinates we have to break them down into the simplest polygons— triangles. We load the models obj file into a custom Mesh parser, which sorts the vertices, and vertices into Triangles.

2. Transformations (Rotation and Movement of Camera along axes)
   Once the model data is loaded, transformations are applied. These transformations are handled through matrix multiplication (which can be thought of as linear transformations) of rotation matrices, and transform matrix.

3. Projection (3D –> 2D Conversion)
   After transforming the model, the next step is projecting 3D coordinates onto a 2D screen. I implemented a perspective projection matrix, which is just another type of linear transformation that simulates 3D perspective in 2D, by making things farther away look smaller, and vice-versa. This uses homogeneous coordinates (just add an extra dimension (w) ) which helps to add translation, as it is impossible to do translation with matrix multiplication.

4. Perspective Divide (Normalization)
   Following projection, each vertex undergoes a perspective divide, where the x, y, and z components are divided by the w component. It gives true perspective and converts the coordinates into NDC (−1 to 1)

5. Rasterize (What is Shown on screen)
   Finally, the normalized vertices are converted into screen space tiny pixels. I filled the triangles by calculating the cross-product of edges. For lighting, I took the dot product of surface-normals and view vector.

Thats just the gist of graphics programming, there is so much more to explore and add that i haven’t even touched. But overall I love this project, and I hope you also would find it cool and like it and maybe even try it out for yourself. :)