# Is there a game not using meshes for models? [closed]

Traditionally, models consist of lots of vertices connected by triangles. That forces the use of a high amount of vertices for detailed organic shapes or makes models kind of blocky. Even though polygon models can be smoothed by subdivision algorithms, this slow, not that exact or still needs a lot of vertices.

Instead, models could be represented by 3 dimensional splines, bezier patches, nurbs or something similar. This way, we would gain perfectly detailed models instead of blocky one with much less vertices. I am not an expert but I assume that a spline could be even rendered faster than its polygon representation. To make the such mathematically perfect shapes more detailed, we could use displacement mapping.

The only big challenge I can see is projecting those splines in the correct perspective. We can simply multiply all vertices with a projection matrix since they are not connected by straight lines. Instead the parameters of a curve must be modified to fit another perspective. I am not sure if there are mathematical straight forward ways to do this.

Are there games using the latter approach?

-

## closed as not constructive by Byte56♦, Anko, Josh Petrie♦, Maik Semder, Sean MiddleditchJun 6 '13 at 18:10

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

And you'd have a universe full of problems: physics and collisions will become extremely heavy unless approximated by mesh primitives, the graphics cards might require some radical redesign (how would you solve depth sorting with spline surfaces given as mathematical objects on a hardware??).. Level of detail algorithms also need another approach.. All in all, NURBS should be the curves you're looking for, right? As for games using the approach, maybe someone has heard of a hybrid, but there's no obvious title that comes to mind today. – teodron Jun 6 '13 at 10:08
@teodron Thanks for your comment. You pointed out some challenges I hadn't though of. Would you post an answer with the information above so that I can mark it as accepted? – danijar Jun 6 '13 at 10:36
There are loads of graphics techniques that don't use meshes, but I don't know of any that run fast enough to work as games. Mostly because we have dedicated hardware for vertices. – Lewis Wakeford Jun 6 '13 at 11:27
At GDC over a decade ago (in 2001 I think) I saw a presentation by the developers of some nature themed game full of wildlife that used splines so that geometry detail would scale as the camera zoomed in and out. I don't remember the name of the game though, sorry. – jhocking Jun 6 '13 at 11:59
@jhocking That sounds exactly like what I am looking for. I haven't found the presentation or paper with the information you remembered, though. – danijar Jun 6 '13 at 12:27

You're looking at points on a continuum as if they're alternatives - Consider resolving a NURB to screen resolution, i.e. each pixel ties to an evaluation of the NURB for that point - the end result is that you're moving from a set of continuous functions to a discrete representation produced by evaluating those functions at specific points.

In the most general case, the only way to truly use NURBS and other continuous representations as the only graphical elements would be to return to the old X,Y driven analog monitors, and off the top of my head, I think transparency would be a complete beast at that point. Now, this is pretty much the way ray tracing works minus the rendering to a monitor, but remember that ray tracing is certainly not performance oriented, and at the end of the ray tracer, it still comes down to dealing with individual pixels being rendered in an image plane of some defined size.

It's not the projection of the spline or the NURB control points that's the rub, it's the tesselation/rasterization of the surface, i.e. the movement from a continuous to a discrete space.

What you can do is load up on graphics cards, dedicate a few as compute engines processing the NURBS, splines, and other such functionally defined surfaces into extremely high resolution triangles, and then feed the resultant triangles into the cards actually doing the rendering. Technically, at a high enough resolution you're pretty much indistinguishable from volumetric rendering from the perspective of the cards doing the rendering.

One other thing to consider is that evaluation of complex parametric surfaces can be expensive (or really cheap which is what makes sphere's so lovable) and you certainly don't want to pay the butchers bill for repeatedly evaluating a static NURB on every frame - but then the question comes as to where you will store the discrete data and then you're under memory pressure to identify the flat bits to drop the storage bill

So, a better way of looking at it would be to say that, given a world where the basis definition of a shape comes from continuous surfaces, where and when should the discrete representation of that shape be generated - Ray tracers say not until the very end of the pipeline, most interactive applications say as soon as possible and please don't fiddle with it after that :-)

-

Take a look at raytracing-based graphic engines.

Raytracing theoretically allows any geometrical shape as long as it is possible to calculate where it intersects a line. That's why demos of raytracing engines like spheres so much - perfect spheres are the bane of polygon-based rendering because they can only be approximated. But they are trivial to do perfectly for raytracing-based renderers. On the other hand, raytracing engines can also handle polygons pretty well when needed.

The downside: Current graphic hardware isn't designed for raytracing. They need to be calculated solely on the CPU. This makes high-quality raytracing too slow for most real-time applications. But the current advances in GPGPU technology (performing arbitrary calculations on the video card) are gradually leveling the playing field in this regard.

-
Current graphics cards do support GPGPU and ray tracing is trivially parallelizable.. I think Google can back this statement up quite easily. It's not trivial to do it in real time with complicated shapes and a lot of interactivity though: academia.edu/156653/… – teodron Jun 6 '13 at 13:29
Slightly related: 'sfera' does realtime pathtracing and uses only spheres, see e.g.: youtube.com/watch?v=Dh9uWYaiP3s . For something with more complex geometry, see 'brigade engine', e.g. youtube.com/watch?v=n0vHdMmp2_c – sarahm Jun 6 '13 at 16:29

The Ecstatica series used a combination of dynamic 3D characters superimposed over pre-rendered backgrounds. The dynamic elements (and most of the backgrounds) are comprised of ellipsoids.

While the effect looks funny today it's was running on mid 90s PC hardware without any 3D acceleration. At the time I thought the characters (video) were very well animated compared to other games of the era (video).

I'm not sure how it was implemented but the style has always struck me as unique.

-

For instance Outcast

There is something called the voxel technology, it uses point cloud data for rendering.

Is Unlimited Detail real?

No meshes are used here, just points. But as AttackingHobo noted:

• The environment is static. No dynamic lights, animations, or shaders.

• All objects are data heavy both in memory and in storage.

• The amount of unique objects is limited by the amount of memory and storage that the user has.

• Character animation would either have to be standard polygon, use some kind of sparse-voxel character animation technique(computationally heavy), or load a different model for each frame of animation.

So it can not be used with anything that is meant to be dynamic.

-
Last time I checked, they didn't have any games out (June 2013), so it's not actually answering the question, is it? – Maik Semder Jun 6 '13 at 10:17
Actually Outcast is using polgons, aka meshes, as the wiki you linked mentions: `"Outcast's graphics engine is mainly a combination of a ray casting (heightmap) engine, used to render the landscape, and a texture mapping polygon engine used to render objects. The "Engine Programming" section of the credits in the manual[2] has several subsections related to graphics, among them: "Landscape Engine", "Polygon Engine", "Water & Shadows Engine" and "Special effects Engine". Although Outcast is often cited as a forerunner of voxel technology,[3] this is somewhat misleading."` – Maik Semder Jun 6 '13 at 10:34
Thanks for you answer. Thus you gave an answer to the question title, my question described in the text is specially about models defined by curves. By the way, voxel models can be animated and shaded, too. – danijar Jun 6 '13 at 10:50
If you think that it isn't a useful answer I can delete it – Mikolaj Marcisz Jun 6 '13 at 10:54
I second Maik on this issue. Volumetric methods do require the extraction of meshes since you'd need primitives to feed the gfx card. Their awe and glitter might come from their somewhat mystical view they benefit from the public.. but they don't have much if anything to do with curves/surfaces as geometrical tools. – teodron Jun 6 '13 at 12:07