Am 04.12.2009, 20:12 Uhr, schrieb Christopher Barker <[email protected]>:
> Nitro wrote: >> [...] > > However: > > 1) OpenGL is pretty darn low-level. We've had to write WAY too much code > to do simple stuff like drawing a filled polygon, and it has essentially > not text support at all. We're using our own 3d engine anyways, so this is not an issue for us. > 2) A lot of OpenGL, or at least GLU, requires lots of individual calls > to the library, often one call per vertex: for polygon tesselation, for > instance. Doing this in Python is a performance killer. We're looking at > using Cython to write C version of some of this stuff. If you make proper use of OpenGL this should not happen. It sounds like you use OpenGL like it was used in version 1.0. Even version 1.1 supported things like vertex arrays. Nowadays vertex buffers and such are very much the standard. This avoids many of the calls. If you use Direct3D 10 or 11 you can render myriads of objects with very few calls. This also relates to point 1). Maybe you should look into 3d engines which have an api to do this stuff, and they do it as fast as possible. It sounds like you're reinventing the wheel. Not meant offensive, but I've worked on an engine like that for 6 years now, so I know how much work you can put into this kind of thing before you have it working all the way you want it to work. > 3) You don't get a full range of transforms. As it looks from your note, > the full-featured arbitrary transforms are costing a lot in FC2 -- We > found the same thing in Chaco. We've approached that by essentially > having two copies of the data around -- the raw data in "world > coordinates", and a copy transformed into a linear, orthogonal > coordinate system. We then let GL do the panning and scaling to pixel > coordinates for us. This works pretty well, as you only need to do the > transforms when new data is added or changed. You get nice fast zooming > and panning. The full-featured transforms don't have much cost really (as long as you don't move lots of nodes simultaneously). The final transforms are computed and then cached and only re-evaluated when something in the node's chain changes. The only thing that happens each render is multiplying the camera transform with the world transform (in OpenGL terms: compute the model-view matrix), but this has acceptable speed and is not a major problem. > However it doesn't allow the arbitrary nested transforms that FC2 has. From what I can see they're not too useful anyway. In OpenGL you can always use a vertex shader for arbitrary functions on your input data. > 4) There are also issues with stuff that you don't want to scale: like > text and objects that stay the same size as you zoom. You have to > change that size on each render -- you get some help 'cause you can > often use the same data that's already been passed to GL, though, but > you do end up making a lot of calls in a python loop on each render. You could simply split your objects into world-space objects and screen-space objects. Render the world space objects with your regular transform and the screen-space objects with a special matrix/vertex shader. > 5) how stuff is rendered is somewhat left up to the video card, some > make prettier results than others. You should be able to control all of that. E.g. you can specify which multisampling (antialiasing) level to use, mipmap bias, texture filtering (e.g. anisotropic) and so on. -Matthias _______________________________________________ FloatCanvas mailing list [email protected] http://paulmcnett.com/cgi-bin/mailman/listinfo/floatcanvas
