740 replies to this topic

[vogliadicane]

for the graduated "disable lighting" there's a bug:

 

When I enter 0,04 the result is correct, but after the first run it changes to 3,921..... (something like this). Only the value is falsely displayed, but works correctly to my observation.

 

and: this feature is really so helpful, I like it a lot!

Edited by vogliadicane, 09 August 2017 - 08:13 PM.

[sliderpoint]

Here is an odd request...  Can we have an 'block transmit' option on walls, ramps, prims?  the scenario I have is:  there is a light with transmit under a bumper cap. That works great.  But I have a clear plastic Ramp above that and I don't want the light to also transmit through it too.

 

ps. thx for looking in to the crashes.  I'll wait for the next build to see if I still have other editor crashes.

 

-Mike

[dark]

I'd like to see the need for raised PF's eliminated altogether one day.

[bent98]

I would love to have the jaggies elimated as I think that' s the single most glaring limitation of vp right now. Sadly I don't think it will be address until vp11.

[krille81]

I would love to have the jaggies elimated as I think that' s the single most glaring limitation of vp right now. Sadly I don't think it will be address until vp11.

I run vpx in Highest DSR resolution and the jaggies is gone. try that

Skickat från min E2303 via Tapatalk

[toxie]

for the graduated "disable lighting" there's a bug:

 

When I enter 0,04 the result is correct, but after the first run it changes to 3,921..... (something like this). Only the value is falsely displayed, but works correctly to my observation.

 

and: this feature is really so helpful, I like it a lot!

 

it's still correctly displayed, as it has a e-02 at the end, although that floating point format display is very odd for a UI, i agree..  :/

@fuzzel: any simple way to avoid that this format is chosen for display??

[hauntfreaks]

I would love to have the jaggies elimated as I think that' s the single most glaring limitation of vp right now. Sadly I don't think it will be address until vp11.

 

tell builders to stop using 1024x2048 PF's   .... hehehe   

[fuzzel]

for the graduated "disable lighting" there's a bug:
 
When I enter 0,04 the result is correct, but after the first run it changes to 3,921..... (something like this). Only the value is falsely displayed, but works correctly to my observation.
 
and: this feature is really so helpful, I like it a lot!

 
it's still correctly displayed, as it has a e-02 at the end, although that floating point format display is very odd for a UI, i agree..  :/
@fuzzel: any simple way to avoid that this format is chosen for display??

Hmm maybe if you round the float number? The UI doesn't convert the value it just shows the ascii representation of it.

Edited by fuzzel, 10 August 2017 - 06:59 AM.

[toxie]

 

I would love to have the jaggies elimated as I think that' s the single most glaring limitation of vp right now. Sadly I don't think it will be address until vp11.

 

tell builders to stop using 1024x2048 PF's   .... hehehe   

 

 

that's not a problem though, as the gfx card will filter that one nicely to match your display.. its all the geometry, normal maps and lighting that causes this..

[Drybonz]

I would love to have the jaggies elimated as I think that' s the single most glaring limitation of vp right now. Sadly I don't think it will be address until vp11.

 

All the flaws are exposed when you blow a lower res image up on a large cabinet screen.  AA helps, but as Hauntfreaks said, hi res images make all the difference.  

[fuzzel]

rev3167 is up:

 

- add/remove a selected element to/from a collection via the context menu

- fixing potential null pointer access

[bent98]

 

I would love to have the jaggies elimated as I think that' s the single most glaring limitation of vp right now. Sadly I don't think it will be address until vp11.

 

All the flaws are exposed when you blow a lower res image up on a large cabinet screen.  AA helps, but as Hauntfreaks said, hi res images make all the difference.  

 

 

As toxie mentioned that has nothing to do with it. Look at Body dump or flupper tables. They dont use low res PF images and have jaggies. How about ramps? They have jaggies galore. 

Edited by bent98, 10 August 2017 - 08:10 PM.

[DJRobX]

 

 

that's not a problem though, as the gfx card will filter that one nicely to match your display.. its all the geometry, normal maps and lighting that causes this..

 

 

There's still something that's fundamentally "off" about VPX's output though, as Bent98 noted, particularly in ramps.    If I look at TPA on my iPad 3, it's razor sharp with no jaggies.  This, on a weak, relatively old mobile device. 

 

With VPX I can mostly fix this by turning on Brute Force 4xaa, but doing this has super steep GFX card costs.    I don't really understand why I need such heavy graphics card requirements just to show a simple statically rendered wire ramp cleanly.   

[fuzzel]

That's because of the static rendering state. VP renders every static element into an extra texture and an extra depth buffer. For each frame these static buffers are used to render the dynamic elements on top of it. All the AA stuff is a post rendering shader step with nearly no hardware support but only done by the shader itself. TPA renders everything each frame even the 'static' elements are dynamic. I don't know the details how TPA renders everything of course but that is what I suspect it does.

VP11 will support the dynamic rendering and we drop the static rendering process once for all. Once we changed the rendering pipeline in that way we are ready to start implementing BAM stuff

[hauntfreaks]

 

 

 

As toxie mentioned that has nothing to do with it. Look at Body dump or flupper tables. They dont use low res PF images and have jaggies. How about ramps? They have jaggies galore. 

 

I noticed if a table is using VPX wire ramps, I can see jaggies on the curves, but when primitive wire ramps are used , I get no jaggies....

what flupper table are you referring to??... never notice jaggies on any of his....??

here an example screenshot (extreme closeup) from my cab with an old gtx760ti and only Brute Force 4xaa on...

Edited by hauntfreaks, 10 August 2017 - 11:37 PM.

[bent98]

I still see jaggies on the wireform on your pic albeit reduced more than other elements on that screenshot. At the end of the day, who cares if the wire form ramp looks smoother when so many other elements in that screenshot has jaggies?

That's because of the static rendering state. VP renders every static element into an extra texture and an extra depth buffer. For each frame these static buffers are used to render the dynamic elements on top of it. All the AA stuff is a post rendering shader step with nearly no hardware support but only done by the shader itself. TPA renders everything each frame even the 'static' elements are dynamic. I don't know the details how TPA renders everything of course but that is what I suspect it does.

VP11 will support the dynamic rendering and we drop the static rendering process once for all. Once we changed the rendering pipeline in that way we are ready to start implementing BAM stuff

 

VP11 cant come fast enough.

[hauntfreaks]

I still see jaggies on the wireform on your pic albeit reduced more than other elements on that screenshot. At the end of the day, who cares if the wire form ramp looks smoother when so many other elements in that screenshot has jaggies?

That's because of the static rendering state. VP renders every static element into an extra texture and an extra depth buffer. For each frame these static buffers are used to render the dynamic elements on top of it. All the AA stuff is a post rendering shader step with nearly no hardware support but only done by the shader itself. TPA renders everything each frame even the 'static' elements are dynamic. I don't know the details how TPA renders everything of course but that is what I suspect it does.

VP11 will support the dynamic rendering and we drop the static rendering process once for all. Once we changed the rendering pipeline in that way we are ready to start implementing BAM stuff

 

VP11 cant come fast enough.

wait?.... you see jaggies in that pic?.... you on a 800x600 monitor??....lol...lol

[jpsalas]

 

 

I would love to have the jaggies elimated as I think that' s the single most glaring limitation of vp right now. Sadly I don't think it will be address until vp11.

 

All the flaws are exposed when you blow a lower res image up on a large cabinet screen.  AA helps, but as Hauntfreaks said, hi res images make all the difference.  

 

 

As toxie mentioned that has nothing to do with it. Look at Body dump or flupper tables. They dont use low res PF images and have jaggies. How about ramps? They have jaggies galore. 

 

 

My wire ramps don't have jaggies The jaggies on the wire ramps are there because of the environment texture

[jimmyfingers]

Haunt, in your screenshot above when you say extreme close-up did, you zoom the table size in VPX first then render and screenshot the result?  If that's the case, then it's not an apples to apples deal as anything zoomed in on the table via editor / view settings creates more geometry per screen size and smooths everything out all that much more (I and others have done that before with screenshots for sections of tables and with 4xAA on it can look super smooth).  But that doesn't help when we have to zoom back out to view / play the whole table.  I see you say you have brute force 4xAA on so if you're also zooming in the table view / size settings on a 1080p monitor you'll be getting potentially the equivalent of like 8k or 16k resolutions if it was rendered for the whole table. But in any case, can you clarify how exactly you zoomed in / got the "extreme close-up".  

 

I still see a lot of jaggies myself even with brute force and using the HV style view even with brute force 4xAA and 2560x1440 resolution.  I think the more angled items in desktop view and HV / FSS views show the problem of VP and lack of AA more than the FS views, which are closer to rendering a table in a more linear and straight fashion.  I can't do VP at all without brute force 4xAA on and have had to throw money and hardware at the problem as well as time on overly unoptimized tables to try and get to play properly and smoothly.  To be fair though, my setup is using a true 120hz monitor so "costs" more and even though I'm using 1440p resolutions, the HV view and sizing of the backglass and tables makes it a whole lot less demanding then a FS table would be at 1440p.

 

In all fairness, current brute force 4xAA in VP is extremely demanding on GPU power (especially the higher resolution you go), but I'm glad at least we have the option over just FXAA.  More up to date AA will be welcome and if it has to wait, but also can be done with VP 11, then at least part of the performance drop offset by going all dynamic in that version can be gained back by getting real AA working undoubtedly much more efficiently and not having to use brute force 4xAA.  

[ganjafarmer]

Question to devs:

 

Is it possible to add "Possibility of bounce/jump" to physics? Maybe even two options, like max. height of bounce and randomize variable so it's not flying every time you hit given object.

 

I love that effect when u brick hard on post and ball jumps, last days i go hard with real pins and i'm mostly miss that flying ball.

 

I know we can recreate that effect with few lines of script like it's done (beautifully) in BTTF vpx but i'd like to see this option in gui, belive me it will change gameplay on some tables and add a lot of realism with visual effect.

 

 

Last days i've seen impossible things going on Metallica table (real one in public loc.), ball bounced off the left slingshot very hard and went airborne mode, flew above right lane, bounced off the apron and went to drain. I was like wtf.

 

Here is similar action but guy was lucky and ball flew to plunger lane: https://youtu.be/7seWKtz_0zc?t=5m15s