Uploaded July 2016 | Updated September 2026, 2 weeks ago
How the hell is that even possible?! D:
Edit: I probably pressed too hard on the display and killed it. Now it is stuck in the middle of the screen... :/
Edit: I finally opened up the display. The bug was stuck between the backlight and the actual LCD. I carefully removed it with a paper towel without letting any dust get inside. Now the display is properly working again.
How the hell is that even possible?! D:
Edit: I probably pressed too hard on the display and killed it. Now it is stuck in the middle of the screen... :/
Edit: I finally opened up the display. The bug was stuck between the backlight and the actual LCD. I carefully removed it with a paper towel without letting any dust get inside. Now the display is properly working again.
![PhysX3D [GRAVITY SIMULATION] Galaxy fly-through + Blooming Effekt demo
Recently I have improved the blooming effect in terms of performance by about two magnutudes.
Blooming is a rendering effect which makes the otherwise black space between close pixels brighter. It is a post-processing effect, meaning the completely rendered frame is being edited as an image right before being drawn on the screen.
The improvement that I implemented was instead of going through the frame pixel by pixel and checking the surrounding of each pixel, at first to scan the frame for all non-black pixels and to save their positions, so the algorithm only has to iterate through the amount of drawn pixels instead of the whole frame.
More information at: http://www.projectphysx.de
Music: Puddle of Infinity - Open Sea Morning PhysX3D [GRAVITY SIMULATION] Galaxy fly-through + Blooming Effekt demo](https://i.ytimg.com/vi/WbbjvGIfqdc/mqdefault.jpg)




![Simulating terminal velocity raindrop impacts with FluidX3D at Reynolds number 51k
Simulating raindrop impacts is particularly challenging for CFD software, because the Reynolds number Re=d*u/nu is very high and for such turbulent flow many solvers become unstable. With D3Q19 and the SRT collision operator, the LBM solver FluidX3D is still stable at Re=51k despite the free surface extension, enabling proper raindrop impact simulations without cheating on the viscosity.
References for simulation parameters:
[1] https://www.researchgate.net/publication/256687896_Effects_of_Altitude_on_Maximum_Raindrop_Size_and_Fall_Velocity_as_Limited_by_Collisional_Breakup
[2] https://www.engineersedge.com/physics/water density_viscosity_specific_weight_13146.htm
FluidX3D is a real time 3D fluid simulation based on the lattice Boltzmann method. It is written in OpenCL C (GPU code) and optimized to the physical limit (video memory bandwith, ~520GB/s).
All demonstrations are simulated and visualized on a Nvidia Titan Xp. Compute time of all simulations combined was about 15 minutes. Graphics are done with the OpenCL C version of Line3D, the fastest graphics engine ever written for primitive shapes like lines, dots and circles. It can handle up to 2 billion lines per second.
The free surface is done with the volume-of-fluid (VoF) extension to LBM. It allows simulating free surfaces with a sharp interface layer.
The volume force (gavity) is implemented with the Gou forcing scheme.
Visualization of the surface is done with the marching cubes algorithm (implemented in OpenCL C).
http://paulbourke.net/geometry/polygonise/
Hardware Setup:
CPU: Intel Core i7-8700K @ 4.5GHz all core
GPU: Nvidia Titan Xp
RAM: 2x8GB Corsair Vengeance LPX DDR4 3200MHz CL16
Mainboard: ASUS ROG STRIX Z370-I GAMING
SSD 1: Samsung 970 PRO 512GB
SSD 2: Samsung 860 EVO 1TB
CPU Cooler: Cooltek LP53
PSU: Corsair SF600
Housing: Fractal Design Node 202
Timestamps:
0:00 - Intro
0:06 - 1 mm drop size
0:13 - 2 mm drop size
0:21 - 3 mm drop size
0:28 - 4 mm drop size
0:36 - 5 mm drop size
0:43 - 6 mm drop size
0:51 - 7 mm drop size
More information at http://www.projectphysx.de Simulating terminal velocity raindrop impacts with FluidX3D at Reynolds number 51k](https://i.ytimg.com/vi/ZxMQnUX9fjw/mqdefault.jpg)

![Line3D [GRAPHICS ENGINE] Dynamische Beleuchtung
Ich hab noch ein bisschen an der Java-Grafikausgabe aus meinem Projekt PhysX3D weiter geschrieben. Aus einfachen Linien sind Polygone geworden, die dynamisch von einer (oder auch mehreren) frei beweglichen Lichtquellen beleuchtet werden. In diesem Beispiel berechnet die CPU auf einem Kern 25.600 Dreiecke pro Frame, und das etwa 30 Mal in der Sekunde.
Ich verwende dazu nur die elementarsten Java-Bibliotheken wie das JFrame, ein Fenster, in dem ich Linien, Text und Vielecke zeichnen kann.
Wie funktioniert die Berechnung?
Für jedes Dreieck wird der Normalenvektor berechnet. Das ist sozusagen eine Linie, die immer senkrecht auf der Fläche des Dreiecks steht. Dann wird der Normalenvektor skalar mit dem Vektor vom Mittelpunkt des Dreiecks zur Lichtquelle multipliziert. Einfach ausgedrückt vergleicht man dabei, ob der Normalenvektor zur Lichtquelle zeigt. Wenn er das tut, ist die Fläche heller, sonst dunkler. Mit dem Ergebnis der skalaren Multiplikation wird die Helligkeit des Dreiecks skaliert.
Die Lichtquelle muss nicht immer am selben Punkt sein, sie kann sich auch bewegen, wie hier im Video demonstriert.
Was ist der praktische Nutzen davon?
Das Prinzip der dynamischen Beleuchtung ist heutzutage in jedem Computerspiel und in jeder Rendering-Software zu finden, bloß werden dort die Dreiecke noch viel kleiner gemacht, damit zum Beispiel ein animiertes Gesicht nicht eckig aussieht. Line3D [GRAPHICS ENGINE] Dynamische Beleuchtung](https://i.ytimg.com/vi/_9i8RSxTkjA/mqdefault.jpg)


