how to make "smooth openGL objects"?

[Lionheart008]

good morning, I have a general question to OpenGL topic (glut, freeglut and so on). What's the main reason that most of the primitives created with tbgl (thinbasic) or other openGL examples (I have used some powerbasic lessons the last time) are not perfect "smooth" or "round". I can use for openGL primitives: a) antialiasing or b) glEnable with %GL_POINT_SMOOTH, %GL_LINE_SMOOTH and/or %GL_POLYGON_SMOOTH. But the result is nearly the same for me that the edges of the polygon faces aren't smooth or round. In CAD application they are using constructive solid geometry (CSG). There are primitives very smooth as I can see. I think about cubes, torus and spheres. I see and notice some 3d application (blender, silo, cinema, maya and much more) at the 3d market and all primitives and objects are fantastic round and smooth. these companies are don't working with openGL or with directX ? I would be appreciate to get some infos about this behaviour of missing the smoothness for tbgl objects, thanks, best regards, frank btw: good work and nice layout with the new forum!

[Petr Schreiber]

Hi Frank!,

that is very interesting question. The reason is purely practical - current accelerators work with polygon representation of the surfaces. More smooth the surface is, more polygons are produced and the speed goes down and GPU memory higher.

Todays mainstream GPUs don't have that big problem with polycount, but low end such as Intel graphics cards are very sensitive to high polycounts. I remember last time I checked performance characteristics of Intel card (1,5 year ago), even using very optimized approaches such as Vertex Arrays, Vertex Buffer Objects or Display Lists, the limit was slightly over 30 000 polygons at real time speed (textured, lighted). In the same time, comparable GPUs from ATi or NVIDIA can render 3 000 000 polygons at least.

So there is still need to optimize, if you need to ship to all hardware platforms.

Many CSG programs have nicely rounded shapes, but it comes at the price - you might notice for example in SolidWorks that:


screen is not refreshed continuously, only when needed
during the rotation and other movements, the decal of objects goes down, sometimes into extreme where things like complex wheel model for example get suddenly replaced by box during the rotation, to keep the experience real time
the performance is not exactly realtime for models composed from multiple objects


In TBGL, you can control the level of detail for objects using TBGL_SetPrimitiveQuality, so with really high detail level, the shapes become round.

I attach simple example demonstrating change of primitive quality during manipulation.


Petr

P.S. Currently, there is very exciting new technology with brand new cards, where tesselation (subdivision of rough surfaces to look smooth) is accelerated in hardware. But as it is implemented only on last generation of hardware, TBGL does not contain support for it yet. But to optimize performance, there are some precalculations done when changing primitive quality setting, but the render then goes at full speed.

[Michael Hartlef]

Hi guys,

regarding the smooth look of objects... there are two aspects to look into.

1) Vertex normals. For an example, when you select the smooth option in BLENDER, it doesn't create new geometry but recalculates the vertex normals.

2) Surface subdivision. This is actually done either by addition more geometry on the fly or via shader programs when you render your output.

Michael

[Petr Schreiber]

Yes, good point.

Smooth normals are enabled by default for all round TBGL primitives, and they can be used on models (or parts of them) as well. It really improves the look a lot, while it is not expensive at all.

The geometry shader postprocess is possible as well, but it seems using the hardware tesselator unit is preferred way for the performance reasons.

I remember even very old ATi cards had tesselator built in, I think it was called TruForm or something like that. It is interesting tesselation in general was widely adopted no sooner than this year.


Petr

[Lionheart008]

thank you both for infos. thank you petr for example that show the dilemma with still modus and move modus of tbgl objects.
I thought a) first of all a good software design is responsible for the smoothness of openGL objects (shapes) and b) didn't belong to the hardware or graphic card processor power, but it seems in that case that (for example) the density of a surface with thousands of polygons is indeed responsible for that smooth object (here: primitives).
So I cannot run smooth openGL objects (using thinbasic, powerbasic) with my old laptop at home with short rendering times ;( I know it's possible for little scenes with cubes, torus, spheres and perhaps a space ship. But how does some it-companies of 3d modelling software manage to create short rendering times for bigger openGL scenes they are looking very realistic ? This kind of companies due this effort to their own "rendering engine" and I am astonished how they built such great results even with old machines. nevertheless it was just a question and I am looking again for a better solution for smooth openGL objects that this method won't be hardware or graphic card depending.
One day I will update to the actual computer 3d high-end-power-super-duper packs but I didn't need it so far ;)
thanks, frank ps: I was kicked out (after some few minutes) of the forum during writing my message ! I am writing fast, don't forget! It's possible to expand the edit times ?

[Michael Hartlef]

Petr has experienced this kickout symptom already and Eros set it to 25 minutes a few days ago.

[Petr Schreiber]

Frank,

could you please run this script on your PC?:
http://www.thinbasic.com/community/showthread.php?7848-TBGL-troubleshooting

It could tell us how capable your GPU is and what can you expect from it performance wise.

Regarding speed of model software, they for sure use some more optimization approaches, such as visibility detection for whole blocks. If they are not in view, they don't send it to render at all. This can be also tracked in TBGL using TBGL_IsPointBehindView or TBGL_IsPointVisible, or some other custom approaches, it depends on application (occlusion queries and so on).

In outdoor game rendering city you could check for visibility of whole buildings, in some machine engineering application just the parts and so on. There is sadly no general purpose miracle solution to the rendering speed fixing.



I am looking again for a better solution for smooth openGL objects that this method won't be hardware or graphic card depending
Every rendering method will be always graphic card depending, by its nature :) With some optimization approaches you might get lower framerate than without them for simple scenes.
The only rasterizer I am aware of which can render scene of any complexity without frame rate changes is that part of brain responsible for generating dreams :p


One day I will update to the actual computer 3d high-end-power-super-duper packs but I didn't need it so farNo need to go for super-duper, get any modern Nvidia or ATi card and you'll be happy. I am developing on GeForce G210M, which is "low end" solution, but I am very happy with it, from both features and performance point of view.


Petr

[Lionheart008]

hello. 1) I've found an old tbgl example with "dancing torus" I made some month ago. I noticed that there was missing simple "TBGL_SetPrimitiveQuality" command. I added just this one. For my purpose the result is ok now. Thanks for the useful hints petr. more to come at later moments. 2) @petr:) personal favor: One thing, sometimes I think I would like to understand more about the whole abbreviation world behind all tbgl commands to have my own control about these commands or can add or make new additions. It's possible to get more access to tbgl world? -> I am fear that you will quit some day here at forum in some month years after studying or robot programming ... and then ? ;) It's a serious question! I like and love tbgl module, but there are limitations for me and I am missing more influences /access to openGL features. you have replaced for example: - TBGL_EntityCreateDLSlot (old) with - TBGL_EntityCreateFuncSlot (new) but where's the different why do you changed that? that's only one question as example. nice day, thanks, frank

[Petr Schreiber]

Hi Frank,

thanks for your message!

Regarding me disappearing from TBGL world, as for now it is highly improbable, as I use it both for hobby stuff and also for visualization and tools in the company I work for.

In completely theoretical case I would like to stop with TBGL, I would release the sources for ThinBASIC use so people interested can continue the work. This is also the case of my death, I already instructed my brother what to do in such a case (hide the body, clean up the knife...)



you have replaced for example: - TBGL_EntityCreateDLSlot (old) with - TBGL_EntityCreateFuncSlot (new) but where's the different why do you changed that?
TBGL_EntityCreateDLSlot serves for rendering of DisplayLists while TBGL_EntityCreateFuncSlot allows to specify ThinBASIC function which contains completely user defined object geometric represenatation, not limited to static display lists.

So I am not throwing out any old commands, the TBGL_EntityCreateFuncSlot is an addition, not replacement. If you look into help file, you will find both there.



I like and love tbgl module, but there are limitations for me and I am missing more influences /access to openGL features
Whole OpenGL is accessible using ThinBASIC OpenGL headers. When adding things to TBGL, I usually do not add OpenGL wrappers as it would be redundant. TBGL is not meant to be OpenGL wrapper, it is graphic technology which is based on few elemental principles:


wide compatibility across hardware
syntax for both low level and high level coders
adding commands and functionalities not present in OpenGL
adding only commands with enough universal use
wrapping OpenGL commands only in form of new syntax (adding polymorphism like for TBGL_Vertex, addressing problematic state handling using TBGL_PushState and so on)
making it flexible enough to interop with classic OpenGL when you need to plug in advanced yet not commonly supported features such as shaders


One thing, sometimes I think I would like to understand more about the whole abbreviation world behind all tbgl commands to have my own control about these commands or can add or make new additions. It's possible to get more access to tbgl world?New ideas for TBGL are highly welcome and you can suggest them anytime in Suggest new features (http://www.thinbasic.com/community/forumdisplay.php?222-TBGL-Suggest-new-features) subforum!

For future, I would like to split TBGL to few minor modules, which could also provide some functionality for creators of other modules. I will try the split approach with separate Particles module and decide based on that.


Petr