3889 replies to this topic

[toxie]

2) I was playing around with the AA in the nvidia control panel and made a separate config for vpx.exe.  No matter what combination of settings I tried yield sub par results  However the 4x AA setting in the VPx video options really does a nice job to smooth things out. When enabled with vsync, I got about 52-60 fps but the table has intermediate micro stutter. My video card is a GTX 660ti 3GB. I really don't understand why Nvida AA doesnt yield good result and also wondering if there is more optimization to make the 4x setting in vp run without stutter?

 

As mentioned many times already, 4xAA is the brute force way of sampling (comparable to the hyped "dynamic super resolution" mode of NVIDIA for example), and mathematically the most robust and precise one. We could even have a 9xAA, 16xAA, and so on without problems (but using other ratios (like 2xAA, 3xAA or 8xAA for example), it gets hairy).

As its brute force, there is not much one can optimize specifically there. Its basically like you would just render at a higher resolution.

(all postprocessing is done already on the reduced resolution of the screen though, since the last two builds)

 

The other options (CSAA, MSAA and whatever it is all called) currently do not work with VP, due to technical limitations on how we render things (main reason: the separation of static and dynamic table elements, but also other tiny details). This could all be solved, of course, but currently is not the focus of development for VP10.0.

 

FXAA, TXAA, SMAA and related techniques are pure postprocess options with varying effort to implement (thats why FXAA is in VP for a long time already, as its the most simplistic that works well with all other features out-of-the-box).

[fuzzel]

Would it be trouble to add .3ds to vp10 for model import? If I want just one texture for model .3ds is so much easier

Yes and no. 3DS is much more complicated than .obj but doable.

[randr]

Understood. It just would be nice to have at least another option. Like .3ds

Edited by randr, 04 March 2015 - 01:53 PM.

[Argo]

@Toxie: TXAA ewquires dx11 and i't not just postprocess, also it's pretty blurry and motion oriented, nvidia for maxwell cards also released MFAA, wtih the same quality of 4x MSAA but half the performance hit.

[lio]

I never worked with 3ds max - but how is that easier than exporting an .obj which seems to be THE common denominator among modeling applications? (Honest question)

I just know that it can have a ton of modifiers applied to an object rather than being a fixed "final" mesh which is probably some trouble to import anywhere else with 100% accuracy)

It's just that I think introducing another format could be a source for a lot of problems that might be hard to hunt down if you always have to check what source the model input was rather than focusing on .obj at the moment.

[toxie]

@Toxie: TXAA ewquires dx11 and i't not just postprocess, also it's pretty blurry and motion oriented, nvidia for maxwell cards also released MFAA, wtih the same quality of 4x MSAA but half the performance hit.

 

TXAA as implemented currently/efficiently needs DX11, but by principle it doesn't require DX11 hardware support or anything.. And for me personally it falls under the postprocess category, even if it reaches into the normal rendering pipeline, too..

MFAA is also doable (leaving out the programmable sample positions, these can be approximated), but (as TXAA) requires much more trickery to get it to look right due to the temporal analysis..

[bent98]

 

2) I was playing around with the AA in the nvidia control panel and made a separate config for vpx.exe.  No matter what combination of settings I tried yield sub par results  However the 4x AA setting in the VPx video options really does a nice job to smooth things out. When enabled with vsync, I got about 52-60 fps but the table has intermediate micro stutter. My video card is a GTX 660ti 3GB. I really don't understand why Nvida AA doesnt yield good result and also wondering if there is more optimization to make the 4x setting in vp run without stutter?

 

As mentioned many times already, 4xAA is the brute force way of sampling (comparable to the hyped "dynamic super resolution" mode of NVIDIA for example), and mathematically the most robust and precise one. We could even have a 9xAA, 16xAA, and so on without problems (but using other ratios (like 2xAA, 3xAA or 8xAA for example), it gets hairy).

As its brute force, there is not much one can optimize specifically there. Its basically like you would just render at a higher resolution.

(all postprocessing is done already on the reduced resolution of the screen though, since the last two builds)

 

The other options (CSAA, MSAA and whatever it is all called) currently do not work with VP, due to technical limitations on how we render things (main reason: the separation of static and dynamic table elements, but also other tiny details). This could all be solved, of course, but currently is not the focus of development for VP10.0.

 

FXAA, TXAA, SMAA and related techniques are pure postprocess options with varying effort to implement (thats why FXAA is in VP for a long time already, as its the most simplistic that works well with all other features out-of-the-box).

 

 

That's disappointing as the 4x AA checkbox in VP looks great. Those damn jaggies are so apparent using the nividia control panel AA settings. Kinda of a let down. Is CPU speed or texture memory/GPU speed the limiting factor for 4x AA checkbox performance in VP?

Edited by bent98, 04 March 2015 - 03:38 PM.

[PilzTom]

With my 650Ti Boost I get constant 60 fps with 4xAA via VP settings (Vsync=1, without VSync it is about 71 fps) and all plays very smooth with latest WIP of MonsterBash.

It took me some time because at first I only got 40 fps - unplayable. Reason was that also in Nvidia settings some (FX)AA stuff was set. I explicitely deactivated Gamma correction and FXAA vor VP-Executable there (AA mode is set to aplication controlled) and after that it worked well with very nice picture quality.

[toxie]

That's disappointing as the 4x AA checkbox in VP looks great. Those damn jaggies are so apparent using the nividia control panel AA settings. Kinda of a let down. Is CPU speed or texture memory/GPU speed the limiting factor for 4x AA checkbox performance in VP?

 

 

As said, 4xAA is equal to increasing the resolution, so the GPU is the limiting factor when being compared to disabling 4xAA.

[bent98]

GPU texture memory or GPU core Speed?

[toxie]

Can be both or just one, depending on the actual table.

[ClarkKent]

Best mode is SMAA as there is almost no performance loss (like FXAA) but picture quality is almost as good as 4xAA - not so blurry like FXAA.

[bent98]

too bad we cant use SLI

[bent98]

 

The other options (CSAA, MSAA and whatever it is all called) currently do not work with VP, due to technical limitations on how we render things (main reason: the separation of static and dynamic table elements, but also other tiny details). This could all be solved, of course, but currently is not the focus of development for VP10.0.

 

FXAA, TXAA, SMAA and related techniques are pure postprocess options with varying effort to implement (thats why FXAA is in VP for a long time already, as its the most simplistic that works well with all other features out-of-the-box).

 

 

Is this something that will be worked on after VP 10 is official? I assume CSAA/MSAA might be working in VP 10.1?

Edited by bent98, 04 March 2015 - 06:07 PM.

[Shockman]

The backbox lighting is perfectly in sync with the table now if linked to the night/day slider. Thanks.

 

I have a big problem with this build though. It stems from the fact that the options has its' own window now. Remember I said my table usually, almost always, comes up behind the editor? Before, after I minimized the editor to see the table, play it and exit, nothing is there, I have to hover over the VP icon in the task bar and click the little window that pops up. (Win 8.1) then the editor is back. 

 

But now only the options window comes back when I see and do the same as described. I can not close the options window, and there seems no way to get the editor window back. Instead of clicking the editor window to bring it back, which in this case would only bring back the options window anyway, I have to close (click the X) in the VPX window icon. So I can not edit the table and have a chance to test it before saving, if the usual table behind the editor happens.

 

I don't know if you made the window do that, or I messed up my config. If it's suppose to be its' own window now, maybe an option to dock it would eliminate the problem, but it's just a guess.

 

Knowing the most of the enhancements were done based on feedback, I'm sure this will be sorted in no time. If you could do something to ensure the editor is put to back and the table to front, that would be the bees' knee.

 

This software is incredible. And getting only better. 

[fuzzel]

It's not your fault or that your config is broken or something. I experienced the same behavior and I try to fix that asap. It's this MFC voodoo that is responsible for this

[Shockman]

That's good.

 

I was wondering about the FS backglass image that can now be added. Is that just what will be behind the table, and around if not scaled to show only the inside, or is this an image that will be shown on the second monitor in a cabinet. If so it should be pretty much an unaltered backglass image, right?

[chepas]

Gutted that's it kind of broken it for you at the moment shockman and I think it should be docked by default, but at the same time also decent for other dockable windows too, would be nice to undock the left side 3 panels

 

Options window doesn't open from the view menu but closing is ok.

[fuzzel]

It's the image for the table background. VP can't use the second monitor.

[randr]

Never mind

Edited by randr, 05 March 2015 - 12:00 AM.