GPU not utilized?

[shenxy]

(sorry for my poor English)

I installed a Quadro FX 4800 (with 1.5G RAM) card in a desktop pc (CPU: Intel E5400, RAM: 2G) to run AppLab.

I'm sure that the video card is working since 3DMark Vantage gives high scores to this system.

However, when I tried run AppLab with the a normal motorcycle model, it still takes more than 10 or 20 seconds to render a 500*400 image, and the CPU utilization got 100% when the rendering is in progress.

I suspect that the GPU was not used by AppLab.

I checked the settings in Control Panel of AppLab, both GPU and CUDA were enabled (checked).

What could be wrong?

Attached is the log file.

[ardenpm]

Please check the log output in the Log console in AppLab for any errors or warnings. It is likely that the driver you are using may be unsupported and therefore the GPU is being disabled, if this is the case then there will be a warning/error in the logs regarding this.

Regards

Paul Arden

[shenxy]

Thank you for the reply.

Attached with my post is the log file. There are some warnings. However, I have no clue what the warnings mean and what to do.

BTW, the model was created by RealityDesigner.

Can you help?

[ardenpm]

We do not see any attachement to your post, can you please re-post.

[shenxy]

Attachment is now in the original post. Sorry!

[ardenpm]

Looking at the logs it seems you have final gathering turned on, this is what is taking the significant amount of time. However it should only take that long for the first image, subsquent images should be quicker, are you just basing your information on the first image? You should not measure the rendering performance based on the first frame since it may involve some pre-computation and not represent an accurate measure of performance.

Regards

Paul Arden

[shenxy]

Thank you for your help, Ardenpm.
I'm not just talking about the first frame. Other frames usually take more than 10 seconds.

[ardenpm]

Are you able to provide the scene? Unless there is a very large number of objects in the scene I would not expect it to take this long to render with GPU rendering. I suspect there is some other problem with the scene that is not obvious from the logs. One other thing you can do is run RealityServer with the --gputrace command line option, this will provide much more information in the logs about what the GPU is doing.

[shenxy]

the scene is now attached in the original post. it was exported by RealityDesigner.
thanks!

[ak]

Hello,

We tried the uploaded scene with a similar setup (FX 4800, nt-x86, 2GB RAM) and can confirm that it takes about 10 sec on startup to render an image and again some seconds every time you navigate.
A closer look into the configuration showed that this result makes sense, because this scene has not been setup in an optimal way. See details below:



I would not expect it to take this long to render with GPU rendering.


Your test application has the cpu renderer enabled, that means, if you start the application like it is uploaded, you are rendering on your processor, not on your gpu. There are some ways to change this:
1- Export the scene with 'iray' or 'gpu' render mode selected with RealityDesigner. It looks like you made an export for CPU (default) renderer.
2- Change the application configuration by hand (see attachment change_config.png)
3- Change the application config at runtime (see attachment runtime_config.png)

If you change the scene manually (case 2-/3-), you will see that the iray mode is just showing a black image. This is caused by having the scene lightened with final gathering. As the RealityServer documentation mentions: this illumination technique is not supported by iray.

If you decide despite the above recommendations to use final gathering on a gpu, you might switch to the 'gpu' render mode, but still see long render times. This is caused in the fact, that the final gather mode is set to 1 in the mi file (scene options). As you can read in RealityServer JS API documentation, this mode rebuilds the lightening map every time you request a render image. Thi iis why it takes so long for every navigation step. Changing the fg mode to 'reuse' mode like:

attribute integer "fg_mode" 2
speeds up the render time while navigation.

Besides the mentioned recommendations above, we cannot see a serious advantage to use performance lasting final gathering for this scene at all. Why not adding a simple directional light set before exporting the scene instead? This is supported by all render modes and much faster.

Best regards.

[shenxy]

thank you so much for the help! i'll try the above and let you know the results.

[shenxy]

I managed to have accomplished the following in 3ds Max:
1． Set the render to Mental Ray and unchecked Final Gathering;
2． Added 2 directional lights, with one casting shadow;

The performance with Reality Server dramatically improved, even without a GPU!

Now I’m facing the quality side of the problem: the output quality of Reality Server is far from being satisfactory (please refer to the attachments).

What have I done wrong? Or, what options are there for me to play with to improve the looking?

Thanks!

[ak]

The performance with Reality Server dramatically improved, even without a GPU!


Great!



Now I’m facing the quality side of the problem: the output quality of Reality Server is far from being satisfactory (please refer to the attachments).

What have I done wrong? Or, what options are there for me to play with to improve the looking?


This can be caused by a lot of different reasons.
What is the 3ds Max version you are using? What RealityDesigner version was in use to do the export and what RealityServer version has been called to load the application?
Did you see any error messages from RealityDesigner during the export process (e.g. that a shader cannot be exported properly)? Or are there any warnings in the log output when the scene is loaded by RealityServer?
To make a reasonable statement from our side about this, we need to have the above questions answered and the scene (or a similar test) uploaded to reproduced the behavior.

Best regards..

[shenxy]

3ds Max: 2010
RealityDesigner: 3.0.0.65-115086b
RealityServer(AppLab): 3.0-110630.2535.1918

I did't see any error or warning messages when exporting with RealityDesigner.

I noticed some warning messages in the log:

1.18 IMI io warn : C:\mental images\RealityServer Developer Edition\applications\bmw\scene\scene\include\main_ objects.mi, 37: photonvol options not supported
...
1.18 IMI io warn : C:\mental images\RealityServer Developer Edition\applications\bmw\scene\scene\include\main_ geometry.mi, 19: trilist's data is not supported and will be ignored
1.18 IMI io warn : C:\mental images\RealityServer Developer Edition\applications\bmw\scene\scene\include\main_ geometry.mi, 11675: Approximation technique distance not supported.
1.18 IMI io warn : C:\mental images\RealityServer Developer Edition\applications\bmw\scene\scene\include\main_ geometry.mi, 11675: Approximation technique angle not supported.
1.18 IMI io warn : C:\mental images\RealityServer Developer Edition\applications\bmw\scene\scene\include\main_ geometry.mi, 11691: trilist's data is not supported and will be ignored
1.18 IMI io warn : C:\mental images\RealityServer Developer Edition\applications\bmw\scene\scene\include\main_ geometry.mi, 11749: trilist's data is not supported and will be ignored
1.18 IMI io warn : C:\mental images\RealityServer Developer Edition\applications\bmw\scene\scene\include\main_ geometry.mi, 12172: trilist's data is not supported and will be ignored
1.18 IMI io warn : C:\mental images\RealityServer Developer Edition\applications\bmw\scene\scene\include\main_ geometry.mi, 48511: trilist's data is not supported and will be ignored
1.18 IMI io warn : The next message was already issued 5 times will now be issued for the last time.
1.18 IMI io warn : C:\mental images\RealityServer Developer Edition\applications\bmw\scene\scene\include\main_ geometry.mi, 48677: trilist's data is not supported and will be ignored

[ak]

All the listed log outputs look harmless.

Could you please upload the 3ds max scene in exactly the same state as it has been when you executed the export via RealityDesigner?

Best regards.

[shenxy]

here it is. thanks!

[ak]

We afraid, we cannot reproduce the reported behavior.
When the uploaded scene is rendered in 3ds Max 2010, it looks exactly the same as it is shown on your RealityServer rendering (see attachment).
In addition to that it is obvious that necessary textures are not available in the uploaded zip file, what could cause the difference to the reference picture.
But as mentioned: the consequence on this content mistake is already shown in 3ds Max and has nothing to do with by RealityServer.

Best regards.

[shenxy]

hi ak,

It's strange that the results we got from 3ds Max 2010 differs a lot. Attached please find what I get.

Even so, your result looks better than the output of RealityServer, even without the textures. Take the front wheel for example, the steel and rubber looks more realistic.

I'm now attaching the missing texture images. Could you please let me know what should I do to make the output of RealityServer realistic? If you could make a little change to the scene to improve the results, that could be extremely helpful for me.

Thanks!

[ak]

Hello shenxy ,



I'm now attaching the missing texture images. Could you please let me know what should I do to make the output of RealityServer realistic? If you could make a little change to the scene to improve the results, that could be extremely helpful for me.


We investigated your scene again a bit more in detail and it turned out that a.o. you are using a lot shadings that are not supported by RealityDesigner mapping to RealityServer shading.

For example: some layered bump and reflection maps have been found. As mentioned in RealityDesigner release notes 'Version 3.0.0.55 ... Simple bump mapping now works in iray, rt_bsp, and gpu renderers with the new iray compatible translation rules ... 1. Create an arch+design material in the Material Editor .... The material with a lot reflection maps has not been derived from arch+design material.

We recommend to read the documentation that comes with RealityDesigner and RealityServer.

Attached you can see an example of your BMW test scene, where the texture shader graphs have been replaced by a simple chrome shader. In addition to that we changed the environment color from black to gray to retrieve a nicer global illuminated scene in iray mode.

Hope that helps.

[barry]

Thanks for sending your scene. I also did some quick eval of your assets. I placed arch&design materials and used an HDRI pano for an environment. The attached image ran for ~10min on a single Quadro5800. The scene can be manipulated interactively, then iray converges till you are satisfied. Keep your material reflectances and other properties in a reasonable physical range, stay away from generic phong/blinn shaders. Use an environment rather than setting the reflected color of the materials. Use tone mapping features to dial the lighting levels to where you like.

[shenxy]

hi barry,

your scene looks GREAT!

Could you please send it to us for us to learn how to work with RealityDesigner and RealityServer? Thanks!

Sam

[barry]

Hi Sam,

Here is a pic of your bike in RS with iray. I've attached a zip file of the scene. To save size I removed the textures you had provided and I didn't have rights to share the HDR pano I used. (but anything with a flat center area should work)

You could read this scene right in with AppLab to create an RS test viewer. To gen yourself, make sure you have arch-design shaders applied in max, set up an environment for IBL, use mia_exposure_photographic for a lens shader to tonemap. Export with RealityDesigner using iray as the render option, adjust .mi files if you're having issues. AppLab runs RealityDesigner on .mi files it imports. (you can diff it's output .mis to see what's getting adjusted. mostly shader conversions) If you run across any ingestion or rendering problems, feel free to ping back.

Cheers,

-barry

[shenxy]

hi barry,

your scene looks strange (see the attached screen shots) when i imported into realityserver here. what could be wrong?

[barry]

Most of that is probably reflectivity. The default metals are highly specular. Attach an HDR pano to the environment. (you can find some great panos here: http://www.openfootage.net/?cat=15 or old standbys here: http://gl.ict.usc.edu/Data/HighResProbes/ ) The darkness in the image corners is from the vignetting settings in the tonemapper. IBL lighting with a single color looks flat and reflections start to look like transparency. If you don't care to use IBL, add a ground plane and a couple lights to the scene. With that much chrome and highly reflective surfaces though you'll probably want an environment map at least for reflections.

In the scene I sent there is a reference to texture 1735500025.hdr you could replace that filename with another hdr that you should copy into the images folder as well.

Don't feel you have to match the way I lit the scene. It's more about getting you a workflow that allows you to apply your own materials and be able to iterate quickly.

[shenxy]

I uploaded an HDR file to the scene, it now looks much better (as attached), though the mortorcycle looks like floating in the air. :)

Thanks!

[barry]

Nice. You can use the dome and shadowcatcher to add a ground plane that receives shadows. (doc below) Try using a dome type of "sphere" , with a finite radius. It gives a feeling of parralax when the camera moves and if you're close enough to your object, it won't float(much). Those params are very specific obviously to the HDR image you use for the environment. Looks best with a pano that has a flat mid section. (unless you want your obj to fly ;) )

Also increase your progression steps till interactivity starts to suffer. Performing more steps before you return an image from the server, gets you towards convergence faster. You can also mess with changing that rate while you interact with the scene.

Best regards,

-barry



Dome and shadowcatcher


iray features functionality to use a fake environment dome instead of the infinite environment provided by the environment shader. As this dome is of finite size, camera movements result in positional changes inside the dome and, therefore, the environment lookup changes. Note that the illumination is still computed from the original infinite environment.

The dome is specifified with the following parameters in the options block:
attribute vector "environment_dome_position" 0 0 0
attribute scalar "environment_dome_radius" 100.0
attribute string "environment_dome_mode" "sphere"

The mode can be "infinite" (standard infinite environment lookup), "sphere" (sphere shaped dome), or "hemisphere" (sphere shaped dome where the lower hemisphere is projected on the plane dividing upper and lower hemisphere).

When the dome mode is enabled, an additional "shadow catcher" ground plane can be specified. This transparent plane weights the environment lookup behind it using a progressive estimation of the amount of shadow (for direct light) the ground plane point would receive from the objects in the scene. It can then be used to catch shadows of an object, while the ground still is the environment lookup as specified by the dome settings.

The ground plane is specifified with the following parameters in the options block:
attribute boolean "environment_dome_ground" true
attribute vector "environment_dome_ground_position" 0 0 0
attribute scalar "environment_dome_ground_glossiness" 0.0