Viewport preview render, poor performance, uses single thread?
I've noticed for awhile that the preview renderer in Poser is much, much slower than basically any other graphic software I use. For instance, an identical scene loaded into Blender, 3DS, or DAZ Studio will "preview" just fine using their Opengl rendering.. I can fly around the scene and such with no problems, basically at around 40-60 fps. This is in full-texture mode even with many textures loaded, simple shadows on, etc..
One key difference I've noticed is that while I'm flying around the scene in any other 3D software, the CPU use is around 35-60%. Like, on 4-Core CPU system, I have a scene with millions of verticies, a bunch of 2k to 8k textures with transparency, ... Blender is fine, GLSL shader on uses around 40% CPU flying around, Daz with the same scene is the same, around 55% CPU use. But poser lags like crazy, is completely unuseable. Poser stops at 25% CPU use, 1 core only.
Why is the Poser viewport preview renderer so bad compared to other software? Is there a settings I am missing? I care because when I use simple posing software, I hate DAZ interface, heh. I would rather use poser, but I cannot for increasing number of works.
I opened an old version of Poser and imported the parts of the scene that I could in it, which is most things. It actually worked Much better than Poser 11. It was still laggy, but actually useable.
I looked at more clue with other programs as well. With hardware acceleration turned on in all 3D programs, when panning around the scenes, GPU use is ~ 40% in all programs, some GPU-memory load and little bus load.. The same is true in Poser 8 a well. Moderate GPU use.
In Poser 11, with hardware acceleration turned on, GPU use is around 3%. It appears that there is a problem with the opengl in Poser 11.
It is possible it is my computer, though this problem has persisted through at least 2 completely different hardwares and and several re-install of Windows on clean systems. Always nvidia geforce (680, 1070 are ones I remember) and Intel CPU.
Does anyone else see this problem or is it unusual?
I still spent a little more time playing around with this...
It looks like it may just be kinda wonky programming, part to do with OpenGL and possibly part to do with a programming error..
It looks like, while a complicated scene is loaded, the vast majority of the time spent by the .EXE is in one very small section of the code that appears to be walking a linked-list very frequently.
As a funny test, I was able to "skip" the walking of the list for that code section and this sped up the rendering of the viewport considerably. Instead of like 0.2 FPS, it was up to around 5 FPS.
Beyond that, it looks like the rest of the time is spent in OpenGL calls, but not in ones you'd expect... It's spending another 25% of it's time in CG runtime libraries calling "GetSemanticPolicy", "Internal", "GetError", and "StringAnnotation" not actually doing GL stuff.. I have no idea how the CG libraries work, but a reasonable guess is that it shouldn't be spending a quarter of the CPU time in those functions.
Oh well ! Maybe it'll be fixed in the next poser version, heh.
The preview renderer does not use GPU, it works on CPU only.
The viewport tries to emulate the materials from the selected render engine.
Set the render engine to firefly and the preview ill be a lot faster as when superfly is selected.
Also turn off some of the realism options in the preview mode and lower preview texture size.
The "preview render" is the software used to render the scene in the viewport as one is setting up a scene. It renders the viewport in the same way that a video game "renders" while playing the game, in real-time.
There is indeed a choice between using a software renderer ( SreeD ) or using OpenGL hardware acceleration. If one selects the preview renderer's OpenGL hardware-acceleration option, then I presume that OpenGL is being used to cause the system's GPU to assist with the real-time rendering (as that is opengl's intended purpose for existing). This seems to be the case as I do see the GPU in use (very lightly) and opengl calls being made while flying around the scene. This also seems to be the case since Poser is calling into opengl libraries having to do with hardware accelerated rendering while flying around the scene.
The poser reference manual talks about this on page 86 as well.
If Poser really is using opengl, and other things like the cggl kit to still render in softaware for the real-time rendering in the viewport, so be it, though that would be a little nutty.
for the work that is being done on the CPU, a further observation is that all the work appears to be on a single thread.. basically one core one a processor is going to 100% usage and capping out.
You are correct, I had never realized that selecting firefly / superfly changes the material rendering in the preview renderer. That is new to me.
It does not appear that this slowness has anything to do withe materials or lights however. Setting all materials to slid colors, turning on wireframe only, or even just throwing up large, light-mapped textures on everything seems to make no difference. It seems to be directly proportional to the number of polygons in the scene.
My main observation is that Poser appears to be the only program I use with this problem. Other modeling or posing programs have no trouble with the real-time rendering of complicated scenes. They also appear to use more than one thread, since I can observe all cores being used to perform the real-time scene rendering rather than just one.
I was hoping that I was being a fool and that there was some obvious thing I didn't know about that fixed it. If other people can load scenes with a very high vertex count ( 1M + lets say ) and still see good real-time FPS (30+), then it's me somehow.
So, embarrassingly, I think I figure out sort of what going on..
I went into crazy field-study mode without doing other simple tests.. I load very large number of poser-sourced assets into a scene and although still laggy, was much, much better performance than my imported scenes. I looked to see what might be going on and found that the data poser was churning on in my scenes were the the material name strings, over and over. I simply search-replace the names with simple "texture1" "texture2" names in the files. Once this is imported, performance is much improved.
I guess that somehow the program was having trouble with string text while rendering the frames, and some function in the executable was eating up all the time and not feeding data to the rest of the threads.. Once the names were changed, basically everything became as expected.. scene is faster, GPU is running at ~ 40% usage, CPU is utilizing more than one core.
Well, whatever.. Have to figure out what about strings is a cause, heh.
SF render mode does make the preview render much slower as firefly mode if more complex material nodes are used. This has be known since P11 was released.
The preview render does get slower when large number of polygons are used.
I never use the preview render for animations, but having 1M+ polygons won't get you a 30 frames per second on current CPu speeds. (OpenGl in Poser does NOT uses GPU)
There has been a long debate on preview render speed within the dev team. Going to GPU or switching to DirectX would mean a separate development branch for the preview renderer because of lack of Mac support. So far this has been the reason for not implementing it.
I never noticed the dependence on texture names, that is interesting. Are you using special characters in it?
I am very misunderstanding, maybe.. How does opengl not use GPU? Why is the feature in preview render called "hardware acceleration", "hardware shading", so forth if it does not use the hardware to accelerate or shade?
Mac opengl support is going away, but still exists, not being removed for awhile I think, just stuck on opengl 4 or something like that. It looks like Poser targets older opengl anyway, so for now should still work fine on macs.
I don't know about strings yet. Taking a break. No special characters I am aware of, but longer strings from auto-generation like TextureBase-Tex324321.112.02_2nd.
OpenGL does use the GPU. SreeD mode does not use it. At least that's how I understand it.
If you render some Images in the Preview Renderer I would expect them to use either GPU or CPU depending on your viewport settings, but I haven't checked this.
I can confirm that Poser's viewport speed isn't quite as high as the viewport speed of other applications. I don't have speed problems on my main machine, which has a GTX 970 GPU, but on my laptop I often use the wireframe mode when posing. Also I do make things invisible when not important for the actual task.
I don't need the textured preview anyway. The rendered image looks so much different that I prefer to do test renders for evaluation.