Thu, 09/14/2000 - 13:52
Forums:
Hi. I'd like to know if somebody is having a 'good day' with OpenGl Accelerated boards and Open Cascade on Windows. I've tried both CAS3.0 and 4.0DVP1, especifying (documented) environment variable correctly. The programs run very well, but they behave very slow, compared with a lot of other OpenGl applications, specially when rotating or panning heavier models. The same models give me the better performance in other applications. I've seen in the on-going projects some efforts on improving the Rendering API. Is there something on it I'm missing?
Thanks in advance...
Thu, 09/14/2000 - 21:02
Hi !
Hmmm, it would be interesting to know how much overhead the OpenGL driver layer in Open Cascade has ?, does it take any advantage of hardware acceleration at all, i.e use display lists to save meshes in and so on ?
Mikael
Mon, 09/18/2000 - 15:55
Hi Michael,
that's true , by default, OpenCascade graphics don' use any display-list.
You can try to activates it, using :
1) Modal attributes of the view (attached to a push button)
myV3dView->Set AnimationMode(animates,degenerates)
2) Temporary attributes attached to a mouse button
-> At button press , do :
myV3dView->SetAnimationModeOn()
-> At button release, do :
myV3dView->SetAnimationModeOff()
Explanation :
1) When animation mode is on, all objects contains in the view are bufferized in an OpenGl display-list at the first step of the animation.
2) When animation go on, the full display-list is displayed instead each object separately.
3) The display-list is used until nothing is change (unfortunately, the object detection doing a rebuilt of the display-list because this is not done using temporary graphics excepted in local context mode)
When you use this method you have a gain of 20% or more according the graphic card and driver you have.
4) When degeneration mode is on, all objects displayed in the view are drawn following the degenerate model lied to the object (Wireframe by default) and more only a part of such object can be displayed (ratio parameter).
The degenerate model can be set using
myInteractiveObject->SetDegenerateModel(model, ratio)
model : see Aspect class
This permits to drawn large models with a great improvment of performance ...
PS : OpenCascade core team search a contributor or why not a team of contributor for changing strongly the actual graphic API using more modern conceptual technics to increase a lot the performances in any case and to open the gl functionnalities from the graphic object presentation.
Let me known if you are interested, thanks.
I hope this will be helpfull for you and the graphic planet !
Mon, 09/18/2000 - 21:09
It does sound like there are lots of room for improvements...
I don't think I know enough about the internals of Open Cascade at the moment to be of much help, but maybe later on.
I do not think there is a need for a API independent driver layer between OpenGL and Open Cascade though, today (almost) all 3D graphics are done with either OpenGL or Direct3D and Direct3D is not portable and all Win32 platforms support OpenGL so there is no need for that horrible stuff anyway.
As far as I know there is (almost) no one using PEX or other older 3D API's any more and in any case I think OpenGL are available on all those platforms anyway, correct me if I am wrong.
So keeping a simple layer between Open Cascade and OpenGL should do it I think, and this would make it possible to optimize everything much better.
Allowing all objects to have it's own display list would be a great improvement, one big list is ok as long as nothing change but how often is this true except when you look at some animation.
And what if this big list is to big to fit in video memory, then we are back to a crawling speed, with amany small display lists, at least soem of them will fit in video memory.
There is also the possibility to use vertex arrays/compiled vertex arrays. This is useful if the data changes more often.
Mikael
Sat, 09/23/2000 - 01:21
I wonder if http://www.qubesoft.com/projects/qdraw_1.html could be used as an indepedent layer on top of opengl. it is 1) opensourse 2) hides opengl,directdraw,glide 3) they are very serious ... future port on playstation
I wish i had more time for this ...
Mon, 09/18/2000 - 13:45
About Perf. of OCC I sent a message titled: IRIXSamples Benchmarks on 08/29 That shows that even if you run OCC on SGI Workstation ( ie native OpenGl Graphic Cards and powerfull hardware ) the results are not as good as one could expect, even far from a productive use of OCC. It's quite disappointing, and the only answer I found so far is the use of JAVA for such apllication.That's why I'm trying to test it on Solaris that can be considered as a 'JAVA native OS '. Maybe I'm wrong , I hope that the reasons why we get so low perf is someplace else . Could be settings , OpenGl implementation in OCC etc..Something that can be cured.
Regards
M. KALAI
Thu, 11/20/2008 - 10:18
Hardware acceleration:
Has something changed since millennium?