hello,
i'm glad you find the bottleneck.
but that's what i was afraid of : 2 side lighting are baddly suported on new
nvidia hardware (at least on linux).
(i mean : it's not only on my computer. it use to work fine).
But you should be able to get the same lighting with this option.
this option only force to compute color 2 time per pixel : not only for the
visible face, but for both face of the object.
So, if you got different lighting result, you just have to reverse some light orientation.
i never test performances optimisation using shaders for light.
cheers
c
Le 10/03/2011 06:20, John Harrison a écrit :
Ok so I did something stupid with the [GEMglLightModeli GL_LIGHT_MODEL_TWO_SIDE
GL_FALSE] test which that I connected it to a [gemhead] instead of [gemhead 1].
When I corrected that I did find that indeed the performance changes
drastically for the better. OTOH I couldn't get satisfactory lighting for my
environment. It's a good technique for me to remember and I could probably make
it work even for this project with enough experimentation of lighting sources
and direction but...
it seems clear to me on my system at least with GL_LIGHT_MODEL_TWO_SIDE set to
its default GL_TRUE the bottleneck is the lighting and any gains with a display
list or model are lost because of the lighting issue. However I'm finding that
I get satisfactory performance and appearance by changing the sphere to have 10
segments instead of 30. With a 10 segment sphere I can make 1000 spheres and
straight-line curves at 20fps at about 70% draw on a CPU core. That works for
me! :-)
I was curious if for a future project there might be a way I could make a
shader that would emulate the local lighting effect and do it more efficiently.
Serious exploration with shaders definitely needs to be in my future.
In any case, thanks for all the help!
-John
On Wed, Mar 9, 2011 at 1:55 PM, cyrille henry <c...@chnry.net
<mailto:c...@chnry.net>> wrote:
with lighting on, things did not really change with the model or display
list, but rendering sphere is 2 time slower.
here is the sphere.
Cyrille
Le 09/03/2011 20:44, John Harrison a écrit :
It appears I'm actually getting better results from [gemlist] too with
lighting off. But how do your results change with lighting on? For me, with
lighting on, they seem about the same.
If you have your sphere.obj model with 900 triangles handy, I'd love to
try it.
-John
On Wed, Mar 9, 2011 at 12:19 PM, cyrille henry <c...@chnry.net <mailto:c...@chnry.net>
<mailto:c...@chnry.net <mailto:c...@chnry.net>>> wrote:
here, at 20fps, no lighting, i can draw about 500 model with your
sphere.obj.
1000 sphere 30, and about 3500 display list of sphere 30.
using an other sphere.obj with about 900 triangles, i've got the
same performance than with the display list.
it really is strange that the sphere is the fastest on your
computer.
Cyrille
Le 09/03/2011 19:08, John Harrison a écrit :
Using Cyrille's test patch for speed which he sent into the
list a week or so ago, I tried creating multiple spheres, gemlists, and models.
The sphere is getting the best performance results, unfortunately. Attached is
my test patch. I just connected [repeat] to either [sphere] [GEMglCallList] or
[model] in the patch. The sphere model I used has probably got way too many
points (just found it on the 'net) but my hope was that as the vertices were
static it wouldn't matter.
http://www.eecs.umich.edu/~guskov/eecs598-1/sphere.obj
<http://www.eecs.umich.edu/%7Eguskov/eecs598-1/sphere.obj>
<http://www.eecs.umich.edu/%7Eguskov/eecs598-1/sphere.obj>
maybe one with less vertices will help. I can try...
-John
On Wed, Mar 9, 2011 at 9:48 AM, chris clepper <cgclep...@gmail.com <mailto:cgclep...@gmail.com>
<mailto:cgclep...@gmail.com <mailto:cgclep...@gmail.com>> <mailto:cgclep...@gmail.com
<mailto:cgclep...@gmail.com> <mailto:cgclep...@gmail.com <mailto:cgclep...@gmail.com>>>> wrote:
A model is the way to go since the vertex data is static.
Ideally for situations like this there would be one object that loads a single
model and several clients that just call the display list. Although there is a
lot of memory on GPUs now so 200 models of a sphere won't take up that much.
On Wed, Mar 9, 2011 at 10:32 AM, John Harrison <johnharrison...@gmail.com
<mailto:johnharrison...@gmail.com> <mailto:johnharrison...@gmail.com <mailto:johnharrison...@gmail.com>>
<mailto:johnharrison...@gmail.com <mailto:johnharrison...@gmail.com> <mailto:johnharrison...@gmail.com
<mailto:johnharrison...@gmail.com>>>> wrote:
On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <c...@chnry.net <mailto:c...@chnry.net> <mailto:c...@chnry.net
<mailto:c...@chnry.net>> <mailto:c...@chnry.net <mailto:c...@chnry.net> <mailto:c...@chnry.net <mailto:c...@chnry.net>>>
<mailto:c...@chnry.net <mailto:c...@chnry.net> <mailto:c...@chnry.net <mailto:c...@chnry.net>> <mailto:c...@chnry.net <mailto:c...@chnry.net>
<mailto:c...@chnry.net <mailto:c...@chnry.net>>>>> wrote:
hello,
- try using a display list to render a
sphere, so that every point don't have to be send for every sphere.
see exemple 09.openGL/02.displaylist
you can also use a model with a sphere.obj
to have the same result.
if the spheres are all moving at once, would a
display list still help? Seems like recompilation would have to happen for
every sphere for every frame? I haven't tried the model yet...
yes, the display list will help to render 1 single
sphere.
you have to call it 200 times.
Ok I'm seeing a huge performance difference between using 200 of
[sphere <size-doesn't-matter> 20] and [sphere <size-doesn't-matter> 30]. Huge.
So if I want to keep the sphere with 30 points, I'm thinking gemlist or model are my
answer. I'll try both and report back, unless you have a strong recommendation for one or
the other to save me time.
This list is awesome. Where else could I find help like
this? :-)
-John
_______________________________________________
Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>>
<mailto:Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>>>
mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
--
John
http://alumni.media.mit.edu/~harrison/
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
