DOS demo that used "ellipsoid" technology?
category: general [glöplog]
This one is a real stumper, and I'm only bothering you guys because I can't seem to find this demo in my own archives. I'm trying to find the name and group of a particular DOS demo that used "ellipsoids" for building the objects. (By "ellipsoid" technology, I mean that the objects were created with 3d gourad-shaded spheres and ellipsoids, NOT VECTORBALLS.) An example of what objects built with this technique look like can be found in the game Ecstatica (see mobygames for screenshots, like this one.).
The only other thing I can remember about this demo is that one of the objects was a spider, the background was either a very simple texture or a completely flat color at some point, and that the .zip was definitely under 1 meg (in fact I think the .zip was less than 500K). It was a DOS demo that was released after 1994 (I want to say 1996 or 1997 but I'm not sure).
Does anyone remember this thing, and if so, what the name/group was?
The only other thing I can remember about this demo is that one of the objects was a spider, the background was either a very simple texture or a completely flat color at some point, and that the .zip was definitely under 1 meg (in fact I think the .zip was less than 500K). It was a DOS demo that was released after 1994 (I want to say 1996 or 1997 but I'm not sure).
Does anyone remember this thing, and if so, what the name/group was?
I remember the 4k mercury by digimind that used something similar to the ecstatica method in one part, however I don't remember any other demo using it, so I would also like to find and watch any other demo using the technique.
I am also wonder what exactly does the ecstatica technique. I mean, it's like many solid elipsoid surfaces forming monsters but they aren't rendered in polygons realtime. They are rather rendered as vectorballs, but here the sprites are not spherical to look the same from every angle but the seem to rotate as elipsoid look different from each angle. So are there hundreds of versions of the same elipsoid prerendered on all possible angles in 3D that are just used as vectorballs depending on the position and the orientation? And what happens when the elipsoids are closer to the camera?
I am also wonder what exactly does the ecstatica technique. I mean, it's like many solid elipsoid surfaces forming monsters but they aren't rendered in polygons realtime. They are rather rendered as vectorballs, but here the sprites are not spherical to look the same from every angle but the seem to rotate as elipsoid look different from each angle. So are there hundreds of versions of the same elipsoid prerendered on all possible angles in 3D that are just used as vectorballs depending on the position and the orientation? And what happens when the elipsoids are closer to the camera?
i remember ecstatica but i dont remember any demos using that technique :/
damn, that *is* a stumper.. you sure you didn't dream this, jim? :) there's contrast, but it definitely uses vectorballs.
they're all just stretched vector balls anyways :P
I pondered about this "back then" and doing it in pure 3d way has problems.. on the other hand, if you just handle 3d as lines and do the ellipsoiding in 2d, it should be relatively simple. =)
the one 4k by freestyle?
ps: Actually, they are stretched vector balls with z-buffering. Big difference, this is called "ELLIPSOID TECHNOLOGY NOT VECTORBALLS(tm)".
i remember reading about elipsoid technology in the game reviews when ecstatica first came out. "wow, they can draw stretched balls that intersect each other avoiding raytracing, and since its alot less things to draw then rendeing lots of triangles it looks more realistic and fast!" mindblowing technology :D
its not as if coders flapping their gums about Ultra Technology is new, right?
lovely game, that ecstatica.
lovely game, that ecstatica.
Optimus: No, they were ellipsoids that were gouraud-shaded that were also rendered using z-buffering (special case used because they were all spheres) so that they would intersect properly.
feen: No, I did *NOT* dream it... sheesh :-) I may forget a demo's name, but never its face. I'll keep looking. And contrast used special-case z-buffering with their vectorballs (although it took me my third viewing before I realized that :-)
feen: No, I did *NOT* dream it... sheesh :-) I may forget a demo's name, but never its face. I'll keep looking. And contrast used special-case z-buffering with their vectorballs (although it took me my third viewing before I realized that :-)
Ok, I think I understand. The primary rendering element though is not triangles but elipsoids, taking in account z and shading. The matter is how to render them properly under different angles and distances, at least I can't think of the algorithm right now. For the z-buffered vectorballs in Contrast it's easier to think how to do it though.
Raytrace them and you'll get shadows and intersections for free ;)
Hmm, isn't it easier to just do standard vectorball that is z-buffered. Otherwise they maybe use some special trick, since they have a bunch of information about the type of primitive - and thereby can save lots of calculations (I don't think the other solution would be feasible back then).
But depth, you don't understand, raytracing is how it's done in the real world! It's correct, see? Vectorballs are like polygons, they're just FAKE!
raytracing is not how it's done in the real world. in the real world the light sources shoot light at you, but in raytracing you shoot rays at the scene from the eye.
src, depends on which flavor of raytracing you use. whitted-style recursive raytracing is just BS, path tracing is "backwards" but still converges to solutions of the rendering equation, light tracing starts at the light source(s) and is thus "correct" if you will, bidirectional path tracing starts paths both from the eye and light source(s) and tries to join them somewhere, and there are other variants too (including modifications that properly support participating media and diffraction and get very close indeed to physical reality).
but there still remains the fundamental fact of you completely missing that kusma was being sarcastic :)
but there still remains the fundamental fact of you completely missing that kusma was being sarcastic :)
Projecting spheres as circles is not perspective-correct anyway, though. So vectorballs should become ellipses too. There, I said it.
*bangs head on wall*
someone find the darn demo already!
someone find the darn demo already!
Let's hypnotize Trixter and have him search his mind for more clues.
Battle: Sure it is, at 0,0 and homogeneous aspect ratio :)
I guess I'll have to pour through my 1990s archives and find it... I'll post when I eventually get it.
nothing yet? O_O
projecting sphere doesnt give a sphere? !! can someone confirm this?
well i mean give a circle