Effects in demos that you don't know how they work
category: code [glöplog]
This effect is like Fermats last voxel. Someone scribbled a little 3d voxel effect in a demo and didn't explain it. Now 20 years later...
And it would clearly be impossible to just go in and look at the code.
Do you have the code?
That fucking crow at the end of Starstruck, I mean, I know it's a model but how they managed to sync it the sound so well, and how they managed to make it so realistic in general...? On the Amiga...? :)
Gargaj: Are you saying the binary has been lost? Or that decompilers don't exist?
That's not "code".
The crow? I found it funny when Batman punched its lights out!
I see, then it's impossible to look at it. I guess we'll have to discuss for 18 more years how the effect is done :-)
It shouldn't be that hard to recreate it, the thing is how to do it efficiently. Most of the voxel variations puzzle me but I never tried coding them. For example,. it's nice to draw vertical for voxel landscape or horizontal for twister, but the angled directions could be too much pixel overdraw to fill the gaps, or maybe one could do pre-generated unrolled code that draws at the direction from length 1 to N. Still seems quite CPU intensive, all those voxel effects puzzle me how to do them efficiently and cleanly.
I tried to replicate this effect in our demo 'Enlight the Surreal' - Asm 2000 (around 4:04). Anyway, the way I did it was like (top of my head):
1) Render a quad to an interpolation map containing the Position, ScreenNormal and U/V
2) Loop the interpolation map MAX-HEIGHT count, IF the height map is still below 'MAX-HEIGHT' - render out the texture-color and step the position based on the ScreenNormal
I had an extremely bad choice of height-map and because I was stupid the height couldn't be that big. Also - there is some kind of "sinus"-scaling applied to my version which makes it look even more stupid...
https://www.youtube.com/watch?v=0nEXrYjGLMY&t=262s
1) Render a quad to an interpolation map containing the Position, ScreenNormal and U/V
2) Loop the interpolation map MAX-HEIGHT count, IF the height map is still below 'MAX-HEIGHT' - render out the texture-color and step the position based on the ScreenNormal
I had an extremely bad choice of height-map and because I was stupid the height couldn't be that big. Also - there is some kind of "sinus"-scaling applied to my version which makes it look even more stupid...
https://www.youtube.com/watch?v=0nEXrYjGLMY&t=262s
gnilk: Nice. That was not an bad attempt. Do you remember if the screen-normal also had an z-component or was it only used for lookup? I ask since screen-normal methods usually only simulate surface details on the polygon itself, not above it.
One definitely needs an z-buffer (if one cannot trick it - by drawing like a z-height landscape). Such that each voxel doesnt get occluded by another voxel if it should be drawn behind it.
I think the trick is to get the math right first. Understand how it would really work, and then
optimize the hell out of it using whatever techniques comes to mind.
I think the actual raycast function would have this at the end
One definitely needs an z-buffer (if one cannot trick it - by drawing like a z-height landscape). Such that each voxel doesnt get occluded by another voxel if it should be drawn behind it.
I think the trick is to get the math right first. Understand how it would really work, and then
optimize the hell out of it using whatever techniques comes to mind.
I think the actual raycast function would have this at the end
Code:
// Access height map based on UV coordinates
int current_height = height_map[(int)(u * 256)][(int)(v * 256)];
// Check if the height is below the maximum
if (current_height < prev_maxheight)
I optimized the hell out of this: Pluto128. But doing the height-rendering by testing z-distance on each vertical span. I remember the final heights became quite small because of filesize optimization (by removing those last finaly bytes).
In a triangle or polygon it would require some normal-data to figure out the direction of the voxels of course, if using this technique on other surfaces than the planar or one-dimensional one in Pluto.
In a triangle or polygon it would require some normal-data to figure out the direction of the voxels of course, if using this technique on other surfaces than the planar or one-dimensional one in Pluto.
Speaking of voxels, I've always been fascinated by the voxel stuff in Live Evil
@gnilk: One thing that always bugged me about Enlight the Surreal is: Are there two distinct versions that are not labeled as such? Is it intentional or a bug? Specifically, the recording on Mindcandy has different backgrounds in some examples from what I remember.
I found two captures that highlight this:
Blue background
Green background
Mindcandy has a capture much like the second one, which I interpreted as somehow a buggy background transition (green toruses on blue background didn't look right to me, knowing the other version), but looking at the two captures side-by-side now, they're much more different than what I assumed, with differrent part ordering and all. Even one of the credits is replaced by a different nick!
I found two captures that highlight this:
Blue background
Green background
Mindcandy has a capture much like the second one, which I interpreted as somehow a buggy background transition (green toruses on blue background didn't look right to me, knowing the other version), but looking at the two captures side-by-side now, they're much more different than what I assumed, with differrent part ordering and all. Even one of the credits is replaced by a different nick!
Rudi: Had to dig deep to find the sources, yes - the screen-normal component also interpolated Z and used it to determine visibility.
This is more or less the loop I used. Alpha of color was used as the height value.
A special poly-filler was used to fill the array 'parray' with the correct values. This was done in a second step once all polygons had been rendered to that array.
Apparently I was drawing two pixels - most likely to avoid holes.
This is more or less the loop I used. Alpha of color was used as the height value.
A special poly-filler was used to fill the array 'parray' with the correct values. This was done in a second step once all polygons had been rendered to that array.
Apparently I was drawing two pixels - most likely to avoid holes.
Code:
for (i=0;i<num_parray;i++)
{
xo = parray[i].xofs + ox;
yo = oy+parray[i].yofs;
sofs = xo+yo;
if (zbuffer[sofs] > (parray[i].zval + za))
{
if (parray[i].col.a > h)
{
zbuffer[sofs] = parray[i].zval+za;
sofs2 =oya+parray[i].yofs + oxa+parray[i].xofs;
dst[sofs] = parray[i].col;
dst[sofs2] = parray[i].col;
parray[num] = parray[i];
num++;
}
} else
{
parray[num] = parray[i];
num++;
}
}
@Sesse: Eh, hmm... you are right - but I actually don't remember why. The first one ought to be the final version - as there are many more Toruses.
I think the main reason was a screwup during the compo at assembly. We handed a preview before the deadline (as a placeholder) and got a deadline extension. However, that was not by the compo orgas - so at the end I think the correct version was shown but the wrong version ended up on the FTP server. But we didn't realize until a few days after.
I think the main reason was a screwup during the compo at assembly. We handed a preview before the deadline (as a placeholder) and got a deadline extension. However, that was not by the compo orgas - so at the end I think the correct version was shown but the wrong version ended up on the FTP server. But we didn't realize until a few days after.
bitl: yes, its nice and well executed.
I like these ones also:
Orange - The Nonstop Ibiza Experience
Retroficial by Titan
I like these ones also:
Orange - The Nonstop Ibiza Experience
Retroficial by Titan
gnilk: ah. interesting, I will analyse your code and see if i understand how it works.
rudi: Full code for the part:
https://gist.github.com/gnilk/91d68816127237efadf439e32f57943a
Probably makes understanding that inner piece a bit easier.
For what it's worth - I was wrong about drawing all polygons at once... As you will see...
https://gist.github.com/gnilk/91d68816127237efadf439e32f57943a
Probably makes understanding that inner piece a bit easier.
For what it's worth - I was wrong about drawing all polygons at once... As you will see...
gnilk: thanks. i think some parts of your code is worth looking at. speaking of polygons. i think Robotnik is drawing triangles instead of quads. I tried to look closely at the videocapture. Though, i think its inspiring nevertheless.
Its hard to tell wether its triangles or some glitches in the actual texture:
Its hard to tell wether its triangles or some glitches in the actual texture:
yey. hurray for crap shit browser.
fairly certain it's the renderer and not the texture; it appears properly continuous on most frames where the triangle seams aren't visible.
also this shouldn't be terribly difficult to reverse engineer, right? It's all protected mode, dosbox-x has a debugger, ghidra/ida can disassemble/decompile (some quick googling even seems to show plugins for DOS executables, though I don't even think that's necessary, as that looked like it was for real mode), etc. At least figuring out a high level "there are these 3 passes doing roughly this" seems very feasible with a few evenings' work, which is what folks are after here.
(yeah yeah, put your money where your mouth is, blah blah, whatever)
(yeah yeah, put your money where your mouth is, blah blah, whatever)