pouët.net

I think that's a fitting example of a case where you don't want to be tied down by algorithms, even a high-level choice like sort-and-rasterise. E.g. working with modern hardware, sorting and rendering a triangle at a time are two things you mostly don't want to do. In a software engine, per-pixel z-buffering may or may not be faster than sorting if the number of triangles is large enough, and some meshes can't be sorted at all.

And what good is a set of triangles? If you're researching algorithms or experimenting with a demo effect that's the sort of construct you might work with, but I think anywhere high-level design becomes a big issue (like a 3D engine say) the more relevant concept is one of a "3D object". The relevant verbs aren't "sort" and "rasterise" but more like "place yourself into this scene", or "scene, please accept this 3D object".

Sure, somewhere at a fairly low level in the engine you may have those "sort" and a "rasterise" verbs, but that's the "algorithm level" I'm talking about, way beneath where the important decisions are made. If you start at that level it can be a very steep climb upwards, and many of the choices you make may cause frustration later on because they force you into design patterns that aren't suited for the overall program.

Since you ask, though, yes, I think triangle is a good candidate for a class (even if it's still little more than a datatype, consider the varieties of triangles there might be: flat, textured, shaded, etc.), as is the set of triangles, and the image.

For that matter, the set of sorted triangles is a good candidate for a sister class to the unsorted set. After all if what you're looking for is a sorted set, sorting an unsorted set is just one way to get there. Let's say you're doing marching cubes over some scalar field, you could just align the sampling grid with view space. Thinking in terms of a rasteriser class that can do "whatever" is helpful:

Code:

class unsorted_triangle_set ...
class sorted_triangle_set ...

..

Renderer::please_render( unsorted_triangle_set UT ) {

sorted_triangle_set ST = UT.produce_sorted_set();
please_render( ST );

}

Renderer::please_render( sorted_triangle_set ST ) {

for each t of ST, rasterise t ...

}



Further abstraction would get rid of the triangle set, or, make it derive from a "shape" class (and you'd have to turn that around slightly to do it in C++ anyway). But the point is with that higher-level structure there's a much clearer description of what you want to do, as opposed to how you want to do it. The framework should reflect firstly that you're trying to render a shape, and secondly that you have a way of doing it.

A better solution would be a renderer that's aware of whole objects and makes decisions on how to construct the final sorted set of triangles (or unsorted, or DX buffer object, or whichever fits the situation) with a broader awareness of the overall scene. That's one of the places where OOP and "interface first" thinking really shines, I think. I've done enough 3D engines the other way around to never want to do it again. ;) Nowadays I prefer to have a scene class, a hierarchy of classes for stuff that goes into a scene, then I have a renderer that attaches to a scene, and so on. And I'm happy to write class definitions for days before anything even compiles, because it really pays off in the end. I think. :)

Basically it's hard for me to ascertain the quality of a design that does not serve any computation or operation.

As for your remark that "algorithms are an implementation concern." Algorithms can be as high level as you make them to be. At the design stage they don't even have to be described in terms of the minute operations that they are performing it.

(Algorithms are more abstract and generic than classes)

whynot2000- Is an OOP CPU really something that can be created?

If so, would you be able to write an emulator for a regular procedural CPU to emulate that OOP CPU?

that's the problem, you lost contact whit the system when you do OOP.

that's the problem, you lost contact whit the system when you do OOP.

there is no real optimisation anymore or anything.

there is no real optimisation anymore or anything