Page 1 of 2 12 LastLast
Results 1 to 15 of 16

Thread: Massive openGL Speedup, help..

  1. #1
    Registered User MrFurious's Avatar
    Join Date
    Jun 2006
    Location
    Melbourne
    Posts
    161

    Massive openGL Speedup, help..

    I've more or less always experienced annoying openGL slowdown as I begin populating my scenes with objects, and in most cases the slowdown is unjustifiable ie, not really THAT many objects, poly-count within reason etc. for a long while now I've been trying to isolate the cause and I think I've found it (or at least one cause) and it seems to be due to the specular map of the object.

    I have a simple scene with a single object: a relatively simple sofa, around 300,000 polys. The sofa material has a colour map, specular map, and bump map. In the perspective viewport, openGL navigation, panning, zooming etc is painfully slow, maybe 4 frames a second. Even with ALL the openGL render flags OFF, the openGL speed is the same. (I'm using GLSL Shaders - see attached screenshot for my GL render flags in the prefs panel).

    Now here's where things get interesting... if I open the specular map for the sofa material and DISABLE it, by unchecking the tick next to the layer name, openGL navigation does speed up, to about 10fps..not bad. BUT here's where things get really interesting.. if I shift click the spec texture to delete it completely, whoa.......... openGL moves to WARP SPEED at least 60fps at a guess.

    What I can't understand is why disabling or even deleting the specular map has such a dramatic performance increase, especially since Lightwave currently doesn't even support texture mapped specular highlights?.. furthermore is there possibly a workaround where I could enjoy the huge performance boost but not have to disable.. or even delete my spec maps?.

    Click image for larger version. 

Name:	opengl prefs.jpg 
Views:	231 
Size:	118.6 KB 
ID:	127511

    Test Scene:
    http://www.mediafire.com/download/uk...wdown_Sofa.zip

  2. #2
    The quick workaround would be to swap it out until you need it to render. Is your scene still slow if it's hidden from opengl but still ticked on to render? This way you could have a proxy geo in for visual feedback purposes but the real one will still render for F9s and VPR.
    My opinions and comments do not represent those of my employer.
    www.ernestpchan.com
    www.zazzle.com/gopuggo

  3. #3
    Dreamer Ztreem's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    4,102
    I always use Multitexture instead of GLSL that speeds up the OpenGL view a lot.

  4. #4
    Super Member JonW's Avatar
    Join Date
    Jul 2007
    Location
    Sydney Australia
    Posts
    2,235
    Also make sure every surface has some level of Smooth Threshold, say 1%. There are some threads on this issue.
    Procrastination, mankind's greatest labour saving device!

    W5580 x 2 24GB, Mac Mini, Spyder3Elite, Dulux 30gg 83/006 72/008 grey room,
    XeroxC2255, UPS EvolutionS 3kw+2xEXB

  5. #5
    pass:sword OFF's Avatar
    Join Date
    Feb 2003
    Location
    Russia
    Posts
    967
    Same lags on this scene with Quadro 4000. Just turn view option in to Shaded mode and feel relieved ))

  6. #6
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,803
    I downloaded provided by you scene,
    had to skip missing stuff (Octane & db&w)
    and the first impression - awesome speed.

    Went to Prefs > GL, and I have Multitexture Shaders,
    switched to GLSLShaders,
    ohhh, it's jumping 20-50 times slower or so with it.

    Indeed, killing specularity texture is fixing GLSLShaders issue with it, and now it's working at normal speed.
    LightWave Plugins
    Global Materials for LightWave 2019
    Custom plugin writing. Request a quote.

  7. #7
    Quote Originally Posted by MrFurious View Post
    I've more or less always experienced annoying openGL slowdown as I begin populating my scenes with objects, and in most cases the slowdown is unjustifiable ie, not really THAT many objects, poly-count within reason etc. for a long while now I've been trying to isolate the cause and I think I've found it (or at least one cause) and it seems to be due to the specular map of the object.

    I have a simple scene with a single object: a relatively simple sofa, around 300,000 polys. The sofa material has a colour map, specular map, and bump map. In the perspective viewport, openGL navigation, panning, zooming etc is painfully slow, maybe 4 frames a second. Even with ALL the openGL render flags OFF, the openGL speed is the same. (I'm using GLSL Shaders - see attached screenshot for my GL render flags in the prefs panel).

    Now here's where things get interesting... if I open the specular map for the sofa material and DISABLE it, by unchecking the tick next to the layer name, openGL navigation does speed up, to about 10fps..not bad. BUT here's where things get really interesting.. if I shift click the spec texture to delete it completely, whoa.......... openGL moves to WARP SPEED at least 60fps at a guess.

    What I can't understand is why disabling or even deleting the specular map has such a dramatic performance increase, especially since Lightwave currently doesn't even support texture mapped specular highlights?.. furthermore is there possibly a workaround where I could enjoy the huge performance boost but not have to disable.. or even delete my spec maps?.

    Click image for larger version. 

Name:	opengl prefs.jpg 
Views:	231 
Size:	118.6 KB 
ID:	127511

    Test Scene:
    http://www.mediafire.com/download/uk...wdown_Sofa.zip


    Yes specular takes a massive hit in GL when you use a texture. Always has. That is why Multitexture just looks over it where GL does not. Also it also depends if you have Streaming or Buffered on. Buffered is slower since it has to look at the light then update then comp to the buffered. Where streaming is updating per frame. Try this get rid of your specular texture, add some basic spec, leave on GL and change it to streaming instead of buffered. You will see the GL shaders are looking at the light all the time and streaming that info in. Now with buffered and a basic spec there is only one value buffered so no update needed. With a texture assigned it has to do a lookup per pixel and this is where GL takes the hit when buffered or streaming. Try this, load the scene and set opengl lights to 0. Draw polygon is fine, draw pixel per light is where the hit is taken and GL is not the best as spec with a light that can move.. Its why most 3D apps just do the basic value all the time in the viewport. Also why so many like PBR cause you can see the spec. Course a compiled shader and basic GL are two different beasts.

    -M
    I was thinking of the immortal words of Socrates - "I Drank What??"

  8. #8
    Registered User MrFurious's Avatar
    Join Date
    Jun 2006
    Location
    Melbourne
    Posts
    161
    Yep Ztreem & MSherak, It looks like the best overall option is to use MultiTexture as it ignores specular maps in openGL. The problem is indeed the double-sided checkbox (I'm really starting to hate that damn thing)

    OFF.. shaded did work well even with GLSL shaders but I wanna see my textures!

    Ernpchan, good suggestion but I'd rather not have to deal with proxy's where possible most of my scenes are under 5 million polys and I don't believe it should be necessary to use proxys for a scene of that size.

    JonW I'm sure I recall reading somewhere that the 1% smoothing trick was a legacy issue and has been resolved in later builds. I think I understand why this would speed things up, if there is smoothing between 2 polys then openGL doesn't need to render the 'step' in between the polys. I definitely notice a speed increase with smoothing on, but only if the smoothing is visible, ie: a smoothing angle of 1 does nothing. The higher the smoothing angle, the faster it seems.

    MSherak "Try this get rid of your specular texture, add some basic spec, leave on GL and change it to streaming instead of buffered. You will see the GL shaders are looking at the light all the time and streaming that info in. Now with buffered and a basic spec there is only one value buffered so no update needed" I did exactly that and my result was: spec tex removed, basic spec applied, GLSL selected... streaming is extremely slow and buffered is fast. But if I understood you correctly I should have had the opposite result?

    I've setup a scene with the sofa and an instancer with an array of 48 sofas and a grand total of 14.37 million polys. Regardless of any specular maps, as long as the double sided box is cleared on both surfaces.. it's wonderfully fluid using multi texture shading + texture shaded solid wireframe viewport mode Pushing the limits a little, with 75 instances @22.45 million polys it's a bit stuttery but still quite fast, definitely workable. I'm actually impressed! I've attached the scene if anyone's interested in giving it a go.

    specmap opengl slowdown sofa.lws

    But.. these are just sofas, what about trees...lots of trees and different types. I need to have these backfaces rendered and this is the problem. There must be a way to disable backfaces in openGL but still have them render in VPR/F9. It actually strikes me as very odd, that these 2 are not independent of each other. You can disable textures, reflections, transparency, colour, diffuse, luminosity in openGL and it has no effect on the render so why not double sided?
    Last edited by MrFurious; 07-25-2015 at 12:55 PM.

  9. #9

    JonW I'm sure I recall reading somewhere that the 1% smoothing trick was a legacy issue and has been resolved in later builds. I think I understand why this would speed things up, if there is smoothing between 2 polys then openGL doesn't need to render the 'step' in between the polys. I definitely notice a speed increase with smoothing on, but only if the smoothing is visible, ie: a smoothing angle of 1 does nothing. The higher the smoothing angle, the faster it seems.
    no, like Matt said >
    https://www.youtube.com/watch?v=0LWsRrHnul8
    TheDeadlyAvenger,
    When in Flat shade, the Graphics Card has to effectively unweld points to be able to show polygons flat and hard-edged, which is why any Smooth Shade mode or setting Smoothing Angle above 0 on a surface will always be faster.
    LW vidz   DPont donate   LightWiki   RHiggit   IKBooster   My vidz

  10. #10
    same on a mac pro with an nvidia gtx 980 ti 6G card, OSX 10.10.4 under latest nvidia web drivers. stuttering when in gls shaders mode, unless you remove that specularity map. but even without that map, when opening the sofa in modeler, with almost any mode the handling is just a pain. this video card is not a slow one, so maybe NT needs to fix that. indeed we are all waiting for a better opengl implementation ... some time now.

    cheers

    markus
    3dworks visual computing
    demo reel on vimeo
    instagram

    OSX 10.12.x, macpro 5.1, nvidia gtx 980 ti, LW2015.x / 2018.x, octane 3.x

  11. #11
    Registered User MrFurious's Avatar
    Join Date
    Jun 2006
    Location
    Melbourne
    Posts
    161
    Having to revisit this thread as this problem effects me on a daily basis and I'm near the end of my rope. Currently have this issue submitted with NT as a support ticket but not getting any help there, I thought NT were supposed to be improving communications?

    Hoping to call on the forums to help me test this out on higher end Geforce cards (not quadro). Extremely SLOW openGL performance, even with simple scenes with a 'moderate' polygon count. Below is a cut'n'paste from my support ticket:

    "I've put together a very basic sample scene, some screenshots showing
    display/general/opengl settings, and also a screen recording. (bear in mind
    the screen recording was captured at 15fps) The scene is a single tree =
    468660 polygons, instanced 16 times = 17 x 468660 = just under 8 million
    polygons. I am aware in this particular scene the obvious workaround would
    be to have the instances display as bounding boxes, but this is just a
    sample scene and serves only to show the slowdown in openGL. My actual
    scenes files I use for work usually reach a similar polygon count.

    I've also tried a similar scene with a demo of 2015.3 and had the exact
    same result. I've optimized my nVidia drivers for the best openGL
    performance, and I believe my Lightwave settings are also optimized. (as
    you will see from my screenshots)"

    Here's the link to those who want to give it a go, any feedback is greatly appreciated.
    http://www.mediafire.com/download/f8..._LW_11.6.3.rar

    Deuce from NT was adamant GLSLshaders gets around this issue but I found this was even slower. Even more bizarre, he mentioned 'a developer' (as yet unnamed) did NOT experience any slowdown on a GTX980. So if anyone has a GTX980 or better I'd be extremely interested to see your findings.

    Thanks guys.

  12. #12

    yep, extremely slow

    possible speedups >

    https://www.youtube.com/watch?v=880TOLoJ1SM
    https://www.youtube.com/watch?v=czWBYThz-Zo


    also, LightWave does basically not care what Geforce card you use
    for CPU, LightWave only cares how fast 1 core is, so 4 cores won't help much
    (more cores will help in VPR though)
    Last edited by erikals; 10-27-2015 at 03:27 AM.
    LW vidz   DPont donate   LightWiki   RHiggit   IKBooster   My vidz

  13. #13
    Registered User MrFurious's Avatar
    Join Date
    Jun 2006
    Location
    Melbourne
    Posts
    161
    Erikals.. that's it! Your trex video is basically the same test as my sample scene. Making the surface single-sided isn't an option though if you need to F9 render both sides. The smoothing threshold trick does show a slight improvement but the double sided is night and day. I'm well aware about the double sided polygon issue actually I neglected to add that portion of my support chat: "It's occurred to me that if I uncheck 'double sided' polygons for my most dense objects (or all the objects in my scene), the openGL speedup is IMMENSE. It's the difference between a stuttering 2-5 fps, and a blisteringly fast 30+fps. The difference between an agonizingly frustrating ordeal and an enjoyable and productive work environment"

    So.. that's basically what I'm trying to convey to NT support and suggest a very simple workaround: "I can't imagine it would be a difficult task to simply add a GLOBAL 'hide backfaces' button somewhere in the openGL options, or even implemented as a per-surface solution ie: a second 'double sided' button in the surface editor underneath the existing one which allows 'double sided in openGL only'. Which would make the surface single sided in openGL but would not effect how it renders in F9/F10"

    Who knows what LW2016 will bring OR when it will arrive, LW2016 may negate this issue altogether but that's all speculation and my guess is as good as anybody's. In the meantime this would be an ideal solution, so what if it's a workaround we just need the speed on higher poly scenes right? So frustrating NT support won't even acknowledge this is an issue.

    May I ask what geforce card you're using? Disheartening to see your trex video is dated Dec 2013.. did you submit this to NT as a bug/feature request?
    Last edited by MrFurious; 10-27-2015 at 07:45 AM.

  14. #14

    May I ask what geforce card you're using?
    GTX 470

    Disheartening to see your trex video is dated Dec 2013.. did you submit this to NT as a bug/feature request?
    i read there are big speedups in LW2016 in Layout.... not sure about Modeler...
    LW vidz   DPont donate   LightWiki   RHiggit   IKBooster   My vidz

  15. #15
    geo messy madno's Avatar
    Join Date
    Feb 2009
    Location
    Germany
    Posts
    793
    Even though not asked for, I have cross checked with a Quadro K6000.
    Only with "Geometry Acceleration" set to "Streaming" and / or GLSL shader it is slow. With "Buffered" and Multitexture it is fast. Any other setting does not make a relevant difference. Smoothing on / off = fast; double / single sided = fast. Seems so Nvidia has a limiter in the Geforce driver which they released in the Quadros' one. Could be that LW3DG has not implemented a solution to bypass the Geforce limitation?

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •