666 replies to this topic

[fuzzel]

Does this let you add depth to the table kinda like bam for FP?

Yes. You can add a factor to the z axis and stretch the whole table (make it higher or lower).

Here is a screenshot: left image is the normal one with z scale = 1.0 the right one is with z scale = 3.0 and I had to change the y scale and y offset otherwise the top of the table is out of the screen. I don't know if I should apply the scale factor to every object e.g. triggers get higher too but you decide

Attached Files

•  scale.jpg   39.04KB   13 downloads

Edited by fuzzel, 16 January 2014 - 01:18 PM.

[LoadedWeapon]

Now that's cool..

[unclewilly]

Neat.
I bet with playback settings on a fs table you can get a nice depth to the back of the table.

One question.
Does this effect the ball also?

As it may make the ball appear smaller

[fuzzel]

No the ball isn't changed. You have to set this manually.

[LoadedWeapon]

So can we adjust existing tables to check it out or will it break things?

[fuzzel]

Of course you can use it on all existing tables. It's just a scale factor for the player, if you save a table with this new factor you need the new beta version though.

[LoadedWeapon]

Where is it in the setting? And say if I scale STTNG will it scale everything even cannons and ships or can u scale just table depth? Might look funny on cannons I will have to check it out tonight. Thanks very much!

[fuzzel]

You find it in the backdrop settings. The scaling will scaling all elements. If the cannons look odd after that you have to tweak the primitives by using scale X/Y/Z option of the primitive options.

[LoadedWeapon]

Thanks man I definitely need to work with the editor more to learn how to do more with it than put pictures in.. lol

[Dozer316]

I did some quick testing the z scale factor tonight on a couple of tables, Rosve's Fish Tales was one that had a few weird results.  Around the cross over ramps that are rendered as wire forms the ball sits a fair bit below the ramps as it comes back down to the flippers.   I love this feature though as I have a flush mounted playfield monitor in my cab so any depth of illusion is very welcomed.

 

Would it be a monumental task to render the ball slightly larger depending on ramp height so it gives the illusion of the ball changing height? - This would look very cool at wireform ramp drop points where the ball drops size slightly from larger to smaller as it leaves the ramp back onto the playfield.

 

Thanks a million for the work you guys are doing.

Dozer.

[unclewilly]

Hey dozed,
Can you post a pic of how this looks on a fs table with layback

[jimmyfingers]

Thanks fuzzel for adding the z-scale! So when you say it’s going to take time you mean a few days rather than a few hours J  Man, FarSight and the Pro-Pinball guys could learn something from your delivery speeds

 

I just had a chance to test briefly and the z-scale seems to initially work well for one of the purposes I saw the most need and that was for the newer Hybrid Views that Rascal has been working on / demonstrated.  They looked a bit compressed previously but adding a scale of about 1.5 nicely stretched it out without the disparity of the ball size not changing being a visual problem.

 

As far as the ball size, I imagine that indeed not having it alter is the only way to go as making it stretch visually (vertically) would not look right as it would no longer be a sphere and enlarging completely / proportionately would not make sense as the table is not getting any wider / taller when the z-scale is being set up above 1 (any narrower below 1).

 

I think values of 2 or above for the Z scale will likely not be practical for a few reasons but in addition to the 1.5 mark seemingly being a starting point for HV tables, the FS tables look like maybe setting at 1.2 and reducing layback could help provide some slight depth improvement.  However, I think overall with FS tables it will likely provide more of a fine tuning option / ability between how much of layback to use and how much z-scale rather than radically opening up a whole new world of depth, which I don’t think still can be done too easily with the concept of filling all the screen and the general overhead view of FS in general.

 

To confirm, I imagine it’s just the visuals that are stretching and nothing about the physics (just like the X and Y scales).  So even if the ball looks smaller, it would still be blocked by a wall at height 49, if using the standard ball size of 50, even if the Z-scale has been invoked, correct?

 

Lastly, I think that a little more depth even for FS might be able to be achieved if you could also provide a Z offset adjustment just like X and Y so you could set the perspective of the viewer / camera higher or lower along the Z axis.  This should also help in imitating the varying height of a player from their perspective in front of the table.  With also adding a Z offset function I think we could get a little more tweakability and would be cool to try out if not too much more work.  Plus it would round out the settings screen so that all axis have a scale and an offset parameter – nice and symmetrical

 

People will have to keep in mind if they use it that, as you say, the primitive objects will need their scale along Z altered as well and I imagine matching the value of the general Z offset.  However, that seemed to not be the case with the 3D mesh primitives as they appeared to stretch from what I could tell from my brief tests whereas the native primitives looked like they stayed the same height and would need the Z values on the primitive adjusted (more testing on this item to come).

 

Thanks again for adding this and I’m curious if it’s a ton of work or a totally different arena for the Z offset option.  Also, curious as to other people’s tests / findings.

[fuzzel]

The Z scaling has only an impact on the visuals. It just stretches the 3D objects along the z axis the physics engine is untouched. Regarding the z offset: I thought about adding a 'real' camera where you can set the eye and the target to look at. I made some quick tests today but couldn't get it to work properly, but I think that is possible...

 

@JF: Did you check the trigger object? It scales too but I think it looks quite odd, what do you think should the z-scaling on triggers be removed?

[jimmyfingers]

@fuzzel : I actually had to go back and just check out the triggers on a new / template table as I didn't notice anything with them on the few tables I had tested.  It seems not as many tables still use the visible triggers but I see what you mean in how they stretch up.  However, at a setting of 2, which I think the max useable range would be and likely less, it's hardly noticable at all but you can see the ball drawing through one if looking for it and from the desktop view if one pauses the table and looks for it (at 2 Z scale). 

 

I would almost say leave as is for now but really it's up to you and maybe seeing what some other people think.  I think for the most part it won't be noticed or affecting things for the Z scale ranges that will likely be used based on my brief tests as to how small the ball will start to look if this value is over exploited (and what the screen shot looks like when Z scale is set to 3    It might keep things simpler to not have to remember anything but the ball is exempt.  But that may change as some other things get noticed and / or need to be tweaked.   

 

EDIT:  Noticed what Dozer was talking about after making a few ramp shots on AFM.  There's a problem with ramps and where the ball is actually travelling height wise.  It might be from ramps where the physical one is hidden and a graphical only one in view but may be on all ramps.  Don't have any more time to test now but it's easy to reproduce on most any table.  So close, hopefuly this can be worked out and it won't be a catch 22 with the visual only height change yet the ball / physics not changing.  Maybe you'll have to scale the ball.Z value proportionately too when it's any higher than the table surface.

Edited by jimmyfingers, 17 January 2014 - 12:05 AM.

[unclewilly]

Dumb question but what is the highest supported screen resolution in vp?

Or will it do anything the graphics processor reports

[Dozer316]

Hey dozed,
Can you post a pic of how this looks on a fs table with layback

 

Here's a shot of the latest Whirlpool table with a z scale of 1.6

The layback setting is the default value that the guys set when they built it.   I've also added colored side walls, side rails and a glass texture to the whole table which I do with every table I have on my cabinet to give it a sense of depth (Flush mounted monitor).

Hope this is helpful.

Dozer.

[jimmyfingers]

I was thinking after my previous post on my suggestion about manipulating the ball.Z value but that won't work as it would be a physical change to the ball and would be out of sync with the non-physical changes of the visual only aspect form the Z scale.  However, I hope you can in some way manipulate just the visual of the ball, leaving the physical / collidable as is and then it should still play nice with the other altered objects.  If there's some way to update just the image for the ball to be scalled along the Z axis in height that the ball would travel but times the factor that should work to get rid of the "lower-than-ramps" issue.  I also suspect that 2 tier games would have some oddities but haven't tested ones like black night and the likes yet.

[toxie]

Dumb question but what is the highest supported screen resolution in vp?

Or will it do anything the graphics processor reports

 

i would guess that it's the exact same what windows supports, but could be that directx 7 still has some artificial limit like 4096x4096..

[skinooe]

little question.... Is in Vp someting like face tracking possible to do similar bam in fp. Its a soo cool feature, to change x,y,z in realtime?... At the beginning of bam, rave saild, it should be possible to do it. Is anybody there who can try to start such a hard work?. Motst tablet have a front camera....

 

A big thank to all, who are involved to bring VP in 21th century.

[toxie]

The problem is that VP currently renders stuff very statically, that means a lot of the table is rendered in a pre-processing step that cannot be changed during actual gameplay anymore.

We are working on making things more and more dynamic, but that will need to come along with the long outstanding DirectX9 support.

 

If everything is dynamic at some point in the far future, it will be a piece of cake to reuse raves code for all of that..