What will it take for computers to efficiently draw a curved surface?

[beowulff]

@panamajack

So why did you say, “Both only draw with straight lines.”? Either the curve drawn is smooth or it isn’t, and if it’s made up of straight line segments, it’s not smooth (in the sense I’ve established I’m using, which perhaps I should have clarified before).

To rephrase an earlier question: If the input to the display is an ideal pure sine wave, would you say the curve that results is only drawn with straight lines?

The ouputs from the DAC are quantized. If you filter them, you can reduce jaggedness at the expense of accuracy. Even without filtering, the vectors are going to be drawn continuously (“smoothly”) at some scale, due to slew rate limitations.

But, what I was trying to convey (poorly, I guess) is that digital systems have fundamental resolution limits- it’s impossible for any output device to draw a perfect curve. Whether that matters to the end user is a different story.

[Punoqllads]

Let’s look at how a D/A converter would smooth out a curve that is value y at time t and y + [symbol]e[/symbol] at t + [symbol]d[/symbol] where [symbol]e[/symbol] is the smallest difference in voltage that the original digital signal can represent. For an arbitrarily large [symbol]d[/symbol], you would need a very wide filter to be able to recognize that the line has a slight slope rather than a slope of zero. However, if you make the filter that wide, then you would make a high-frequency sin wave impossible to display. In order to make that high-frequency sin wave displayable, you have to make the filter narrower, which would then make the shallow-slope line appear to be a flat line, followed by a sharper-than-desired sloped line, followed by another flat line.

[panamajack]

edit: nevermind, I understand it now

Of course there’s a limit to what a DAC can output, but beowulff, you implied that it’s impossible for any smooth signal to come out of a DAC + filter. My contention is that you can filter both quantization error and clamp the sampling bandwidth into the noise (expending enough effort on the filter) without much difficulty.

Displays don’t really need to refresh amazingly fast, so it’s not something that requires an impractical effort, either.

[Recliner]

@Capt.Ridley_s_Shooting_Party

There need not be any revolution, we already have the technology: raytracing and other scanline rendering techniques. See any of Pixar’s films for examples of their use.

If you want realtime raytracing, then that’s necessarily limited by computational power. Massively parallel GPUs and CPUs (and the fact that raytracing is easily parallelisable) means its only a matter of time before we see real time raytracers running at resolutions higher than 320x240, too.

For the record, most modelling and animation is done with good ol’ polygons, either directly or indirectly. For example, someone upthread mentioned NURBS – which are curves defined by points which don’t lie on the curve itself, but whos presence defines the curve by – ok, sorry, back to the topic at hand: with a NURBS surface, while the curve itself is mathematically defined, the display of same is, eventually, turned into a triangulated mesh to be rendered. Raytracing of purely mathetmatic algorithms tends to limit you to geometric primitives and other simple objects that can be defined by a simple equation; cartoon-like characters, generally not.

Its possible I’m wrong, but I’ve done a fair bit of 3D (modelling, animating, and rendering), and I know any displayed result (beyond initial primitives) is going to be based on a rendered mesh.