3889 replies to this topic

[Xendo]

I seem to get serious slowdown when the ball enters wire ramps. Normal running fps on my 970 is around 400, but when the ball hits a wire ramp fps drops to `40-60fps.

[freneticamnesic]

Xendo means on wire ramps that are collidable.

On the same table, I get 128fps steady, and if i leave the ramp as default, it drops to 101fps near the end of the ramp. If I select the primitive in the editor and reduce polygons to even .8, it works flawlessly and stays steady at 128 fps.

 

He gets much higher fps with, from what I could see, the same graphics settings, but gets stutter and fps drops even after reducing polygons...

[fuzzel]

Do you mean a primitive wire ramp or the build in version, and what table?

[freneticamnesic]

primitive

all tables that use wire ramp primitives. TFTC does it a bit too.

[fuzzel]

ah ok that's no suprise actually For the collision system a wire ramp primitive is a closed hit object. So if the wires are too close together and touch the ball the collision system is triggered if that happens over some distance the collision calculation gets expensive.

rev2157 is up:

 

- add support for scale the wire thickness of a wire trigger
- fix light insert issue on reflected playfield elements
 

New wire thickness option:

this is actually a scaling factor. 0 means the normal thickness like in previous revisions. If you want to increase the thickness try small values > 0 e.g. 0.5, 1.0 to decrease the normal thickness use negative values.

 

The light insert issue is also fixed when a reflecting element crosses a light insert. Please test this if the light inserts are still working as expected even when no reflecting element is in the insert area.

Edited by fuzzel, 03 August 2015 - 08:22 PM.

[freneticamnesic]

yes but he has a substantially better computer than I have and I have less FPS, and I see no FPS drop or stutter. He gets 4 times the FPS but a significant drop in fps and increase in ball stutter when he's on the same ramp.

[Shockman]

I lost my light off state images with the latest X. 

[lodger]

hey all- i was wondering how people were doing the technique where light shines up through a plastic and seems to make the plastic object glow. is this related to transparency? any help would be appreciated

[freneticamnesic]

the plastic needs to have an active opacity material, and the light needs to have transmit set (I usually do 1 but experiment between .05 and 1 and you get different effects)

 

 

hey all- i was wondering how people were doing the technique where light shines up through a plastic and seems to make the plastic object glow. is this related to transparency? any help would be appreciated

 

edit: transmit, not modulation. woops.

Edited by freneticamnesic, 04 August 2015 - 03:24 AM.

[jpsalas]

hey all- i was wondering how people were doing the technique where light shines up through a plastic and seems to make the plastic object glow. is this related to transparency? any help would be appreciated

The light under the plastic must have the "bulb" enabled. The plastic on top must have a little transparent material (0,99 is good enough). Then you increase or decrease the light property "transmit" until you get the desired effect.

 

 

ah ok that's no suprise actually For the collision system a wire ramp primitive is a closed hit object. So if the wires are too close together and touch the ball the collision system is triggered if that happens over some distance the collision calculation gets expensive.

rev2157 is up:

 

- add support for scale the wire thickness of a wire trigger
- fix light insert issue on reflected playfield elements
 

New wire thickness option:

this is actually a scaling factor. 0 means the normal thickness like in previous revisions. If you want to increase the thickness try small values > 0 e.g. 0.5, 1.0 to decrease the normal thickness use negative values.

 

The light insert issue is also fixed when a reflecting element crosses a light insert. Please test this if the light inserts are still working as expected even when no reflecting element is in the insert area.

 

The wire triggers return to the standard thickness after the ball hits them.

 

The lights seem to be working fine on my tables.

[bitupset]

is it just me, or does "UseDT" always re-check itself upon loading the table again?  i even save the table and it still flips back to checked.  can't find a 'global' setting..???

[fuzzel]

is it just me, or does "UseDT" always re-check itself upon loading the table again?  i even save the table and it still flips back to checked.  can't find a 'global' setting..???

Yes that's normal. You have to enable the cabinet mode in the video settings. The UseDT switch is just for testing.

[fuzzel]

I lost my light off state images with the latest X. 

On all inserts or just on some?

[fuzzel]

Ok wire thickness is fixed and come with the next update.

[fuzzel]

Guys on thing on my to-do list is to change the mesh of the flipper arm. I would like to use a complete mesh primitive based flipper arm like those you see in various tables. The main issue with that is that you would loose the ability to change the rubber thickness/height and width because it would be modeled together with the rest of the flipper but you could scale the length of the flipper. The color would only be changeable by a texture but you could add a logo on the flipper without twiddling with multiple images or primitives. I could add a bunch of different textures with different logos to the default table so you could use that out of the box.

The current flippers are very basic and creating a good looking procedural flipper arm is complicated, especially when you have to texture them. So what do you think? Leave it as is or replace it with a better primitive based mesh?

[chepas]

Flipper bat? Could you add your own in this way and would you have a legacy option like kickers have?

[hauntfreaks]

I'm just thinking out loud here, but... since i've been messing with the lighting in VPX I've had the need multible time where i would have liked to have been be able to rotate a light or invert them horizontally or vertically... are there any plans for an option like this??

Edited by hauntfreaks, 04 August 2015 - 09:14 AM.

[fuzzel]

Flipper bat? Could you add your own in this way and would you have a legacy option like kickers have?

erm no. Adding different flipper meshes from a list or something would intend you have to follow very specific rules to build the mesh otherwise it won't work. I would like to avoid a legacy option for the old flipper mesh generation because this makes thinks very complicated to maintain.

 

I'm just thinking out loud here, but... since i've been messing with the lighting in VPX I've had the need multible time where i would have liked to have been be able to rotate a light or invert them horizontally or vertically... are there any plans for an option like this??

Nope that won't come in this version. Maybe in a next version. Reason for that is that the lights are pure fakes and only look good when they are rendered parallel to the playfield/wall. This way you can apply an off texture and use some blend filters. If the light is rotateable you can't use an off texture anymore because the light disc would cover multiple elements and not only the wall/playfield you attached a light to.

 

Lights will be reworked as soon as we switched to complete dynamic rendering, but that means that all authors have to change their way how they design tables. One future proof way is to use the build in elements just for the collision and not for rendering and only use primitives for all visible elements. Some tables already use that design, like AMH, TFTC, MB or Fire(VP9). Primitives that are static today should then be joined into one primitive when rendered every frame otherwise you will get performance issues (e.g. all screws combined into one big primitive or all plastics are one primitive). Games like TPA or PFX2 are using this approach because todays graphic cards perform best when pumping a lot of polygons with the same render state through the DX9 render pipeline.

[Kaan]

Anyone else is having broken graphics like this on windows 10?

The 3d models are not rendering properly, like the flippers and the bookcase. It is the same with the other tables. I don't have this issue with vp 991. My gpu is gt240m, it is pretty old but it should be fine I think.

[hauntfreaks]

 

 

Nope that won't come in this version. Maybe in a next version. Reason for that is that the lights are pure fakes and only look good when they are rendered parallel to the playfield/wall. This way you can apply an off texture and use some blend filters. If the light is rotateable you can't use an off texture anymore because the light disc would cover multiple elements and not only the wall/playfield you attached a light to.

 

Lights will be reworked as soon as we switched to complete dynamic rendering, but that means that all authors have to change their way how they design tables. One future proof way is to use the build in elements just for the collision and not for rendering and only use primitives for all visible elements. Some tables already use that design, like AMH, TFTC, MB or Fire(VP9). Primitives that are static today should then be joined into one primitive when rendered every frame otherwise you will get performance issues (e.g. all screws combined into one big primitive or all plastics are one primitive). Games like TPA or PFX2 are using this approach because todays graphic cards perform best when pumping a lot of polygons with the same render state through the DX9 render pipeline.

 

 

 

I think i used the wrong terminology I should have said mirror.....  so when you make a shape you make duplicates but mirrored them, this would also be convenient when making walls... sorry for the mixup....