#opengl — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #opengl, aggregated by home.social.
-
somehow realized it's been 25 years since I tried making a 3d game. Linux on a K6-2+ with a voodoo banshee card, all the openGL triangles and quads done by hand with graph paper
-
5 ошибок, которые заставят игру на LibGDX тормозить
Эта статья не про геймдизайн, не про монетизацию, не про продвижение и не про то, почему ваша игра никому не нужна. Речь исключительно о технических ошибках при разработке игры на LibGDX , которые могут привести к низкому FPS, микрофризам, большому потреблению памяти, повышенному расходу батареи или проблемам при сборке под WebGL. Причём в первую очередь я говорю о мобильных играх и WebGL-версиях , которые запускаются непосредственно в браузере. На мощном десктопном компьютере многие из этих проблем могут быть практически незаметны. Я сам разрабатываю игры на LibGDX и периодически наступаю на разные грабли. Поэтому ниже не академический список оптимизаций, а вещи, на которые я бы обратил внимание уже в начале разработки.
-
5 ошибок, которые заставят игру на LibGDX тормозить
Эта статья не про геймдизайн, не про монетизацию, не про продвижение и не про то, почему ваша игра никому не нужна. Речь исключительно о технических ошибках при разработке игры на LibGDX , которые могут привести к низкому FPS, микрофризам, большому потреблению памяти, повышенному расходу батареи или проблемам при сборке под WebGL. Причём в первую очередь я говорю о мобильных играх и WebGL-версиях , которые запускаются непосредственно в браузере. На мощном десктопном компьютере многие из этих проблем могут быть практически незаметны. Я сам разрабатываю игры на LibGDX и периодически наступаю на разные грабли. Поэтому ниже не академический список оптимизаций, а вещи, на которые я бы обратил внимание уже в начале разработки.
-
5 ошибок, которые заставят игру на LibGDX тормозить
Эта статья не про геймдизайн, не про монетизацию, не про продвижение и не про то, почему ваша игра никому не нужна. Речь исключительно о технических ошибках при разработке игры на LibGDX , которые могут привести к низкому FPS, микрофризам, большому потреблению памяти, повышенному расходу батареи или проблемам при сборке под WebGL. Причём в первую очередь я говорю о мобильных играх и WebGL-версиях , которые запускаются непосредственно в браузере. На мощном десктопном компьютере многие из этих проблем могут быть практически незаметны. Я сам разрабатываю игры на LibGDX и периодически наступаю на разные грабли. Поэтому ниже не академический список оптимизаций, а вещи, на которые я бы обратил внимание уже в начале разработки.
-
Back in the day, I made a couple of demos where a Hamiltonian path is carved out on a polyhedron. Looking back, I started to wonder about the shape left around the path, and what it means in terms of graph theory. I call this shape the "dual complement" of the path.
The dual of a polyhedron is essentially the result of turning faces into vertices and vice versa. This is shown in the first clip with a snub dodecahedron and its dual, the pentagonal hexecontahedron; to keep the view cleaner, I'm only showing the edges of one at a time.
The duality transformation also affects the edges, but their number remains the same, and there's a 1:1 mapping between the original and dual edges. Each dual edge "cuts through" the original. To make the dual complement of a path, I remove the dual counterpart of each edge in the path, leaving only the stuff on the sides. It's like driving a snow plough along the path, leaving walls of snow on the sides.
For the final view, I combine original Hamiltonian paths with their dual complements.
#graphtheory #hamiltonianpath #hamiltoniancycle #dualpolyhedron #dualcomplement #snubdodecahedron #pentagonalhexecontahedron #3dgraphics #digitalsculpture #pythoncode #numpy #opengl #creativecodeart #algorithmicart #algorist #mathart #laskutaide #computerart #ittaide #kuavataide #iterati
-
Sierpinski triangles on an icosahedron, inspired by Ghee Beom Kim
#sierpinskitriangle #icosahedron #geometricart #fractal #fractalart #iteratedfunctionsystem #3dgraphics #raymarching #pythoncode #numpy #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
With 2D Apollonian gaskets, it's easy to build arbitrary initial configurations. Simply picking 3 random points means you have to solve for 3 radii to make a kissing setup. Since there are exactly 3 distances between the points, this makes a basic linear system. But not so in 3D: you have 4 points and 4 radii, but 6 different distances, so a linear solution won't cut it. You could start with 3 kissing spheres using the 2D logic, but then you can't put the 4th point just anywhere.
I didn't bother with the messy quadratic system, because there's an easier way: take the symmetric tetrahedral config and deform it using an inversion. Yep, the same tool that's already the bread and butter of gasket-weaving. What's more, we can build the symmetric gasket first and then deform the whole thing. Inversion preserves spheres as spheres and maintains their kissing relations, it doesn't care how many there are.
In other words, the order doesn't matter with inversions. I've used this trick years ago in some 2D inversion demos to simplify things, and this 3D also benefits hugely from it. Besides the problem of initial config, 3D gaskets also have a speed issue due to deduplication (explained in an earlier post). The inversions are very fast as they can be parallelized, and this also applies to the deformations. So it's nice that we need not rebuild the gasket again for every config, we can just deform the same thing again.
#apollonianspheres #apolloniangasket #gasketweaving #iteratedfunctionsystem #inversion #sphereinversion #geometricart #3dgraphics #digitalsculpture #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
Making Apollonian gaskets usually follows a key rule of iterated function systems: each iteration should make the thing smaller. With inversions, this means going from the outside to the inside of inverting circles.
However, it's possible to make valid gaskets using a lopsided configuration, where the initial circles are bunched up on one side. In that case, the first iteration has to make a larger circle to fill the opposite side. This means an inversion from the inside to outside. But we can also think of this as turning the inversion circle inside out.
This turns out nice both visually and conceptually. An inversion circle is essentially a curved mirror, and we can make a smooth transition from the convex to the concave by passing through the flat stage. I wasn't sure if this would work cleanly in this simple demo, since the flat mirror means a circle with infinite radius; fortunately, the finite time steps mean we can skip over the flat point.
As for IFS rules, the system as a whole is contractive, thanks to the other circles that are now more convex.
The second part gives another look at such initially lopsided gaskets.
#apolloniancircles #apolloniangasket #iteratedfunctionsystem #inversion #circleinversion #geometricart #fractal #fractalart #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
Another look at Apollonian spheres, cutting out the top half and showing a few iteration steps.
#apollonianspheres #apolloniangasket #iteratedfunctionsystem #inversion #sphereinversion #geometricart #3dgraphics #digitalsculpture #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
Taking my lastest Apollonian gasket code from 2D to 3D was quite straightforward in principle, though there were a few kinks in the road. A particular difference between 2D and 3D gaskets is that in 3D, the inversion spheres overlap, which can create duplicate spheres.
Viewing detailed 3D structures isn't trivial either. We can only really see in 2D, as one dimension is taken up by the ray of light. Looking from outside, I wouldn't guess this blob contains over 10k spheres, so I blew it up for this clip.
The sheer amount of balls is also heavy on the drawing side, so I used my low-poly "sprites" where each ball is drawn by a geometry shader from a single input point. The low-poly aspect is quite clear in the largest spheres, but I think it's OK for this math demo.
#apollonianspheres #apolloniangasket #iteratedfunctionsystem #inversion #sphereinversion #geometricart #3dgraphics #digitalsculpture #pythoncode #opengl #geometryshader #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
As I keep studying the Apollonian gasket, I've now implemented the inversion approach on the CPU for finding the circle centres and radii. Now I can generate these arrays of eyes much faster, as the inversion is easier to parallelize. It's so fast that the bottleneck is now in the drawing stage.
The colours denote a kind of family tree of inversions: the 4 initial circles each have their own colour, and their inversion images retain the colour. The outer circle is not shown here, but its descendants show the colour that's distinct from the other 3.
I still needed something other than inversions for setting up the initial quartet, but I wanted find my own solution instead of relying on Descartes' theorem. The theorem actually comes in two parts: Rene's original theorem only deals with the radii, while the complex quadratic formula for finding the circle positions was only developed in the late 1990s.
Well, I found an alternative solution to the latter part, and it reduces to a pair of linear equations. It isn't particularly fast to compute, but I think it's easier to understand — it's basically junior high school math. In fact, it seems so basic that I can't be the first one to discover it.
#eyecandy #apolloniancircles #apolloniangasket #iteratedfunctionsystem #inversion #circleinversion #geometricart #fractal #fractalart #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
2D circle inversion fractals on the spherical surface. This was a fun offshoot of my recent Apollonian endeavours, again using the Riemann sphere mapping to go from 3D to 2D for the iterations.
The inversion circle centres come from a tetrakis hexahedron and a triakis icosahedron, so the circles form approximations of a truncated octahedron and a truncated dodecahedron.
#apolloniancircles #apolloniangasket #inversion #circleinversion #riemannsphere #geometricart #fractal #fractalart #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
In the last post, I noted how the incremental iterates of the Apollonian gasket look like the output of an iterated function system. There's indeed such an IFS, and it's a system of circle inversions. It's how I've made a lot of fractal art over the years, but I've usually started directly with the inversion circles/spheres themselves.
Now that I've worked with the "classical" approach to the Apollonian gasket, I thought I'd translate a given Apollonian setup to the language of inversions. It was a fun little exercise and the math was surprisingly simple, just playing with vectors and solving linear equations. I then used my old inversion shaders from the late 2010s to show the results.
The first part shows it all together: the 3 largest coloured circles are the initial Apollonian circles, and the 4 inversion circles can be seen in the darkest grey in the background. (The initial Apollonian circles also include a 4th one, but here we can only see it as the perimeter of the coloured area.)
The second part uses a pointillist process, and it shows essentially the incremental iterates of the previous post. The inversion circles are not seen, but the Apollonian circles are all there as the empty space.
#apolloniancircles #apolloniangasket #iteratedfunctionsystem #inversion #circleinversion #geometricart #fractal #fractalart #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
The Apollonian gasket is a bit peculiar as an iterated system. The Nth stage of circles isn't generated solely by generation N-1, but all of the preceding generations. Alternatively, one might say that each circle also regenerates itself for the next level. Either way, it doesn't work like a typical IFS.
As I wonder how it all works, I'm showing you a couple of different views of the Apollonian iteration. The first part is just the regular progression. The second is the same, but only the newest generation of circles is shown. It looks a bit like a regular IFS as the iteration level increases.
The last two parts show a kind of graph view of the process, with the same structure seen through 2 different cameras. The balls and sticks are scaled in proportion to the circles they represent, and each child is connected to its parents. To avoid messing up the view completely, I've left out the outer circle that encompasses all the others, so a lot of circles show only 2 parents.
#apolloniancircles #apolloniangasket #iteratedfunctionsystem #geometricart #fractal #fractalart #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
The set of polyhedra that can be converted into Apollonian gaskets via sphere-plane mapping is quite limited. The face polygons should be regular, the edge midpoints should all lie on the same sphere, and the vertices should be 3-fold. There are some Platonic solids that work, and I've showed all of these earlier. It turns out that Archimedean solids with 3-fold vertices work too. So here's a truncated octahedron, also showing a progressive view of the gasket iteration.
#apolloniancircles #apolloniangasket #riemannsphere #archimedeansolid #truncatedoctahedron #geometricart #fractal #fractalart #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
Another look at the Apollonian gasket. This shows that the process doesn't use simple inversion, since that would distort the image within each disc.
#apolloniancircles #apolloniangasket #geometricart #fractal #fractalart #biblicallyaccurateangels #weirdart #creepyart #horrorart #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
Back to basics: I made an Apollonian gasket generator based on Descartes' theorem, as explained on Wikipedia. The method involves some nontrivial details on the choice of +/- signs, which I had to figure out on my own.
The result looks a lot like some of the inversion fractals I've done over the years, and they are certainly related. But writing this classical method on the CPU side was an attempt to do and learn something different. Using 6 iterations was a compromise between detail and rendering speed — at 5 or so FPS this wasn't quite realtime, though I guess it can be optimized further.
#apolloniancircles #circleinversion #indraspearls #geometricart #fractal #fractalart #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
Testing the Gosper curve in my variable iteration halftoning setup. So far I've only used the Hilbert curve this way, and things get a bit coarser with the Gosper, so it was harder to find images that make nice results. So here we are with the old Venus again.
The number of points multiplies by 4 for Hilbert and 7 for Gosper on each step, so the latter has to get by with fewer iterations for a sensible resolution. Here we have 6 iterations for 6 grey levels.
#halftoneart #gospercurve #planefillingcurve #spacefillingcurve #singlelinedrawing #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
The previous demo made me dig deeper into dithering algorithms. It's something I should have done years ago, as I've been using simple random dithering now and then, and I hadn't even thought of gamma correction. One algorithm in particular caught my eye: Riemersma dithering, which uses the Hilbert curve. Compared to the usual matrices for error diffusion, the curve approach seemed easier to implement in some ways, as it has fewer edge issues.
More interestingly, it struck a chord with my earlier experiments with space-filling curves in image processing. So it was a kind of familiar territory, but it also seemed esoteric enough that I could imagine making some new discoveries. For example, play with other plane-filling curves besides the Hilbert.
The first image uses the boustrophedon curve, which makes the vertical wave patterns I recall from a number of non-dithering demos. The second curve is what I call the diagstrophedon, a diagonal zig-zag starting from the top left corner, and I think its wavy artefacts make a nice match for Venus's hair.
Then in image 3 we have Hilbert, which doesn't seem to make any particular artefacts, and I guess that's a good thing for dithering. Finally 4 uses the Peano curve, which makes some fun wiggles in light areas.
#dithering #riemersmadithering #stippling #halftoneart #raster #pixelart #hilbertcurve #peanocurve #planefillingcurve #spacefillingcurve #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
Yet another optimized Voronoi tiling. This was supposed to be a simpler alternative to the previous tiling approach, but I ended up going down a rabbit hole of various dithering algorithms.
Instead of the equal-sum partitions, this uses regular dithering to find the Voronoi seed points, and the tile areas are inversely proportional to the colour values. My simple random dithering didn't work as well as expected, so I started to look into alternatives. I was of course aware of Floyd-Steinberg, and as I grew a bit tired of this demo, I ended up cheating a little by using a ready-made library. Since I was using PIL for image handling anyway, I could simply use its format conversion functions to get a 1-bit image, which uses F-S by default.
As before, I planned to use edge detection to get smaller tiles at the contrast edges. However, it didn't work so well with dithering, as it would concentrate basically all seed points at the edges. So here I used a mix of edge detection and the original. I think it worked out nicely here, as the bright colours often coincide with areas of small detail, while the dark background doesn't need much resolution.
#voronoidiagram #pixelart #blockart #tiling #raster #mosaic #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
I wanted to make the optimized tiling look more organic, and I've already played with Voronoi diagrams quite a lot. But this turned out a bit more messy than expected. To preserve the size and shape variations of the rectangles in the Voronoi cells, I ended up using a non-uniformly weighted metric. I guess it counts as a shape metric, using the definition in my Bridges 2020 paper.
As before, there's a roughly uniform tiling with an equal number of cells for comparison.
#voronoidiagram #pixelart #blockart #tiling #raster #mosaic #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
Another visual refinement to a recent demo: adding seams to the optimized tiling scheme. While it breaks the mosaic illusion to some extent, I think it makes the tile sizing idea much clearer. As before, there's a uniform variant with the same number of tiles for comparison.
Source photo: Mary of Egypt by José de Ribera, in public domain.
#pixelart #blockart #tiling #raster #mosaic #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
The recent stipplings and partitionings reminded me of this demo from about 2 years ago. In short, it's a Hilbert curve where the iteration level varies by the colour value. I wanted to make some small changes, but I ended up rewriting it completely. The shader approach seemed needlessly heavy and redundant for something that works more naturally on a CPU. But mostly it was just a fun exercise in looking at the same problem from a different angle.
The first picture shows the original idea. With the new idea, I wanted to get rid of the slanted lines; the result doesn't feel any better to me, but I guess it's interesting in its own way.
#hilbertcurve #planefillingcurve #spacefillingcurve #lineart #linedrawing #singlelinedrawing #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
I came across this halftoning idea sometime last week. While the idea was relatively easy to understand and fun to implement, I've spent quite a lot of time trying to make the result look nice.
In each row, the image is split into bins containing roughly the same sum of lightness value. This is nice to implement when the number of lines/bins is a power of 2, so we can recurse with a binary split. Thus the line density varies by average lightness. The problem is that density is considered along the x-axis. If things change a lot between rows, the lines get slanted, so they appear more dense. Here I've included some averaging between neighbouring rows to make thing a bit smoother.
I'm also including a fun glitch from the early tests. The line-density system includes the set of point coordinates and the graph structure (which point is connected to which). What happened here is my generic graph generator that simply finds the nearest neighbours of each point. So in the light areas that are compressed horizontally, the nearest neighbours were left and right.
#halftoneart #lineart #patterns #texture #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #ittaide #kuavataide #iterati
-
Minimum spanning tree of a dithered image, 4096 vertices. Model: Swetlana
#spanningtreeyoungandsweet #minimumspanningtree #primsalgorithm #graphtheory #halftoneart #lineart #pythoncode #opengl #algorithmicart #algorist #mathart #laskutaide #computerart #ittaide #kuavataide #iterati
-
@Cheryl Furse
> Where is a crypto crash?
2022 especially.
#^https://en.wikipedia.org/wiki/Cryptocurrency_bubble#2021%E2%80%932023_crash
#^https://www.npr.org/2022/12/29/1145297807/crypto-crash-ftx-cryptocurrency-bitcoin
More recently: #^https://www.forbes.com/sites/digital-assets/2023/06/10/bloodbath-sudden-1-trillion-crypto-crash-sparks-fresh-coinbase-warning-and-tanks-the-price-of-bitcoin-ethereum-bnb-xrp-cardano-dogecoin-polygon-and-solana/
> Opensim a success? We are just 200 real people with thousands of alts.
That's your personal perception which you yourself think you "know" for a "fact".
If you really think this is a cold, hard fact, please prove it with a link to statistics.
By the way, here come cold, hard facts: the Hypergrid Business stats from June 15th.
#HypergridBusiness reports 424 active grids. Everyone would have to run at least two grids.
You refuse to believe that number? You think it's made up? It isn't just a number. Here's a list of all 424 grids. Count them. Then check the links. Almost all of them should be active.
125,841 standard regions on the reporting grids alone = each user has to have almost 630 standard regions on average.
#OSgrid alone reported 27,325 standard regions. If everyone had land on OSgrid, that'd be almost 130 standard regions per #OpenSim user.
Also, as of today, by the way, OSgrid lists 5,689 sims (taking varsims into account) on its official website, all by name. Only few of them are official. All the others are hosted by their owners and attached to OSgrid externally. OSgrid does not offer land rentals.
If every OpenSim user had land on OSgrid, everyone would have 28 sims or more on average attached to OSgrid. That's enough land for a stand-alone grid.
If you claim for a fact that this is bullshit, and either OSgrid or its staff makes up most of the names on the list, go in-world and check on the map whether these sims actually exist on the OSgrid map. Mind you, they may be offline. Many of them run on people's Windows PCs which they shut down when they don't need them. Nonetheless, these sims have existed and been online recently.
And that's only OSgrid. On average, everyone would have to own countless sims alll across the Hypergrid.
> I would compare much more with sim city. In opensim anyway, because most are just building landscapes and take pictures of it. SimCity has some more goals. lol
Goes to show you don't get out much.
What people actually do is hoard freebies and party. Female users also play Barbie with their avatars. And some have virtual sex.
But in general, most users don't spend more time than absolutely necessary decorating sims. Look at those many freebie sims that look like they were slapped together within one afternoon.
> You didn't mention thirdroom. Why?
Because I only wanted to pick out a few examples. If I had to include #ThirdRoom, I would also have to cover #VRchat and #Vircadia and #Overte and #RecRoom and #MozillaHubs etc. etc., just to give each and every virtual world out there a fair treatment. The article would have grown HUMONGOUS.
Even when it only came to free, open-source, decentralised virtual worlds, I would also have had to mention and analyse Vircadia, Overte and Mozilla Hubs and rip #Decentraland apart for lying into people's faces.
Besides, I know you're a huge Third Room fangurl. But Third Room is far from being as successful as #SecondLife or #Minecraft or #Roblox. It's a tech preview. It's in a very very early stage. It's far from having a community of thousands, having in-world places that you can spend weeks or months or years exploring, having in-world events etc.
Right now, Third Room is only just barely where Second Life was in 2002, only with public access. It is where OpenSim was in July 2007, immediately after OSgrid was launched, and before people flocked into OSgrid, claimed land and started building.
Also, since Third Room is based on Unity, this blocks creativity. Everything has to be built and scripted outside Third Room. That's like building an entire Second Life or OpenSim sim outside Second Life/OpenSim, scripting it outside Second Life/OpenSim, then dropping the whole thing into Second Life/OpenSim in one chunk, and if you want to change even a small detail, you have to go back outside Second Life/OpenSim and go through almost the whole process again because Unity doesn't let you do shit in-world.
> For opensim I only see one big problem. Stone age technology. Especially because of openGL and Firestorm still thinks we live in a 8 bit world.
32-bit. Second Life wouldn't even be technologically possible in 16-bit, much less 8-bit.
Also, you claim that #OpenGL is stone-age technology because its initial release was in 1992. Well, bad news for you: Your precious, oh-so-powerful MacBook Air M1 runs on an operating system from the age of dinosaurs. It's basically #BSD (macOS is based on Darwin, and Darwin is based on BSD), and BSD is from 1977.
Oh, and by the way, OpenGL has advanced over time. The minimum version required for the official Second Life viewer is 3.2 from August 2009, the minimum version recommended is 4.6 from July 2017.
> This can be changed if there would be young developers interested in creating high end graphics. But you have only nostalgic 60 years old men in opensim who are not skilled to develop new technology.
Another false claim of you which you "know" for a "fact": Everyone in OpenSim except for you is a crusty old geezer at an average age of 60 years.
> Thirdroom has 20 years old kids already who can develop new technology
LOL ROFL
Okay, let's check the factuality of this.
This is the Third Room code repository on GitHub.
The contributors, at least those that aren't bots, are:
Robert Long, software engineer
Nate Martin
Ajay Bura
Matthew Hodgson
Rhea Danzey, senior SRE
Hugh Nimmo-Smith
antpb
Travis Ralston, senior software developer
At the age of 20, you can't be an engineer. You can't have an engineer's degree of any kind. You're still in university or college.
At the age of 20, you certainly can't have "senior" in your official job title.
At least some of these developers don't even look like they're 20. Not 25 either. Not even 30.
So next time you present your personal perception as cold, hard, undeniable facts, prove them. Or don't complain when someone comes with actual facts that contradict what you say and proves these.