Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
mathstodon.xyz is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon instance for maths people. We have LaTeX rendering in the web interface!

Administered by:

Server stats:

2.8K
active users

mathstodon.xyz: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#computergraphics

4 posts4 participants1 post today
Public
claude

Doing some experiments with #RayTracing #ComputerGraphics using #Bonzomatic #GLSL #shader editor.

I define a 24-cell as the intersection of 24 half-spaces in 4D (with normals all permutations of (±1,±1,0,0)), then slice through constant 4th coordinate to get a 3D object, and simulate it as a glass-like material with reflection and refraction.

Future enhancement ideas:

- handle polarised light properly (currently I ignore polarisation, simply averaging the Fresnel reflection coefficients)

- wavelength-dependent index of refraction and absorption

- anti-aliasing (currently the edges are steppy as there is only 1 sample per pixel in a regular grid)

- improve efficiency (internal ray bounce is O(N^2) where N is the number of surfaces, could probably be O(N) with some extra maths insights)

- do 4D->3D slicing on CPU instead of every ray bounce

- add other 4D shapes

#Polarisation is something I haven't done before, so I'm curious to see how to implement it and how it changes appearance.

computer graphics representation of a 3D slice of a 4D object. in the middle is a convex shape bounded by flat planes, reflecting and refracting a surrounding sphere that has glowing coloured bands with soft edges. the object is as if made of glass. the bands visible behind the shape are mainly purple/pink/red, with some parts of the object showing other colours that are behind the viewpoint. the multiple relections and refractions are a bit confusing, when animated the shape is a bit easier to see
Public *
grz0zrg

Wrote some more about extending the "HAKMEM 149 line algorithm" to a quad rasterizer to be able to draw billboards (sprites) up to 3D sprites, the HAKMEM approach (and forward mapping) lose a bit of interest when degrees of freedom (and projection) are added up though but it was fun to retrace the sprites history a bit. :blobcatcomfysmirk:

onirom.fr/wiki/codegolf/main/#

GIF
GIF
#computergraphics#softwarerendering#algorithm
Public *
Jaycosm🔆

I stumbled upon an interesting blog today while searching for an image of the Silicon Graphics 3D cube logo. Named "Abort Retry Fail" by Bradford Morgan White, the blog's articles document computer history. I eventually wound up reading three of them.

#1 "The Rise and Fall of Silicon Graphics"

abortretry.fail/p/the-rise-and

Abort Retry Fail · The Rise and Fall of Silicon GraphicsBy Bradford Morgan White
#AbortRetryFail#Blog#RetroComputing
Public
Hacker News

ProtoGS: Efficient and High-Quality Rendering with 3D Gaussian Prototypes

arxiv.org/abs/2503.17486

arXiv logo
arXiv.orgProtoGS: Efficient and High-Quality Rendering with 3D Gaussian Prototypes3D Gaussian Splatting (3DGS) has made significant strides in novel view synthesis but is limited by the substantial number of Gaussian primitives required, posing challenges for deployment on lightweight devices. Recent methods address this issue by compressing the storage size of densified Gaussians, yet fail to preserve rendering quality and efficiency. To overcome these limitations, we propose ProtoGS to learn Gaussian prototypes to represent Gaussian primitives, significantly reducing the total Gaussian amount without sacrificing visual quality. Our method directly uses Gaussian prototypes to enable efficient rendering and leverage the resulting reconstruction loss to guide prototype learning. To further optimize memory efficiency during training, we incorporate structure-from-motion (SfM) points as anchor points to group Gaussian primitives. Gaussian prototypes are derived within each group by clustering of K-means, and both the anchor points and the prototypes are optimized jointly. Our experiments on real-world and synthetic datasets prove that we outperform existing methods, achieving a substantial reduction in the number of Gaussians, and enabling high rendering speed while maintaining or even enhancing rendering fidelity.
#HackerNews#ProtoGS#3DRendering
Public *
grz0zrg

HAKMEM 149 line #algorithm extended to fill a quad by drawing a second line perpendicular to the first one as it is drawn.

Forward mapping so gaps / overdraws, overdraw is allowed to fix gaps, two pixels are drawn at a time, this works and is still kinda efficient as long as blending etc isn't used, a backward mapper may be better otherwise.

Not sure about the pros and cons though...

Function signature was adjusted and the center of rotation is computed for convenience.

GIF
GIF
p5js code for a rotating / scaled gradient quad built with HAKMEM 149 based line algorithm, a second line perpendicular to the first one is drawn as the first one is drawn. The original line algorithm was a bit more optimized there by downscaling the vector values in the setup so there is less shifts to do in the loop. There may be other small optimizations left over. Not sure about the pros and cons of this method but this was a natural extension to the line algorithm and it may share the same pros / cons, small code and okay efficiency on CPUs such as ARM even with overdraw. It can also be trivially extended to draw a textured quad instead with linear texture fetch. All integers (32 bits) except gradient code. (not optimized)
#computergraphics
Public
Ian Badcoe

#GameDev #ComputerGraphics #Normals #Meshes I am already well familiar with the concepts of vertex and face normals, and I know ways to calculate them for simple, or even quite complex cases. Simple being all smooth, or all facetted. Moderately complex being where we have some sharp and some smooth edges, maybe based on an angular threshold, and can share or split verts/normals accordingly.

But... but... what do we do when the mix of sharp and smooth edges is ambiguous, like in the picture. The red edge is sharp and the three blue ones are smooth, so how do we treat the 4 polygons where they meet at the vertex? There is no clean division between polys which connect smoothly and ones which should be separate rotating anticlockwise from A to D, all the edges should be smooth, so A should share a normal with B, and thus with C and eventually D, but going the other way, from A straight to D, we'd like the line to be sharp and we'd like them not to share. Obviously we can't have both. It's a puzzler...

A diagram showing a corner where four squares meet, the squares are labelled A, B, C and D. All squares are separated by blue lines, except A and D which are separated by a red line...
Public
grz0zrg

HAKMEM 149 line drawing #algorithm with epicycles, this uses two circles with opposite rotation to produce a line, not the most efficient way to draw a line since there is overdraw as it approaches edges but this has no conditionals / divisions, the line setup can be small when the input is polar, lines can be stylized easily as well (into curves), the line setup can use lookup tables, may be very efficient / small on ARM.

The idea came from brettcvz.github.io/epicycles

Hilbert curve drawn with the HAKMEM 149 line algorithm.
Stylized Hilbert curve drawn with the HAKMEM 149 algorithm, half circle version with disproportionate HAKMEM 149 inputs which reveal half of the circle. (no collapse)
HAKMEM 149 line algorithm p5js code, all integers, most of the setup code is unnecessary when the input is polar, all of it can be precomputed as well and reduced to lookup tables. This uses a quarter circle to avoid some overdraw (it will draw an arc instead of a circle if not "collapsed"), it can be adapted to use half of a circle instead by using midpoint coordinates as an offset and half cycle iterations, this is better for stylization. Kinda efficient and tiny on ARM ! Could be used to stylize lines or animations etc. The other way to draw a line with HAKMEM 149 would be a trigonometry based version.
GIF
#computergraphics
Public *
grz0zrg

Simplest way to draw HAKMEM 149 based structure without offsetting / adjusting the seeds, turns out that using one unsigned shift is the 🗝️

Loop is optional.

Two versions for the two different algorithm precisions. Adapted for 512x512.

Code is for a grey scale one but i made a colored one based on exponentially mapped iteration count (classic way to color fractals), this somehow require to offset coordinates for nice colors.

Colored precise (not skewed) version of HAKMEM 149 based structure, colors are exponentially mapped based on iteration count.
HAKMEM 149 structure code (precise; grey scale), adapted for 512x512 framebuffer (last two shifts), 32 bits
Skewed grey scale version of the HAKMEM 149 structure.
Skewed HAKMEM 149 structure code. Adapted for a 512x513 framebuffer, 32 bits.
#fractal#codegolf#sizecoding
Public *
Jaycosm🔆

🚩 "Startup claims its Zeus GPU is 10X faster than Nvidia's RTX 5090: Bolt's first GPU coming in 2026"

The Zeus GPU seems like a ray/path-tracing specific solution, not a real-time gaming GPU. I imagine it would be useful for offline 3D rendering... which I can live with 👍

tomshardware.com/pc-components

Tom's Hardware · Startup claims its Zeus GPU is 10X faster than Nvidia's RTX 5090: Bolt's first GPU coming in 2026By Anton Shilov
#Zeus#GPU#ZeusGPU
SearchLive feeds
About