1488 replies to this topic

[Shockman]

Also some kickers kick at more than one angle, depending for example where they were entered from. (left top saucer on mmpac)

[wrd1972]

Devs, congrats on approaching the next official release. Job well done as usual!

One question. Might it be possible to have a global ball image feature where one could use their favorite ball image, and it could be applied to sll tables? Thete could still be an overide in the table properties.

Thanks again for the hard work.

Edited by wrd1972, 10 June 2019 - 11:34 AM.

[Thalamus]

It is already - but, since it is global it is of course not in table properties. Believe it is under video/graphics Options. One of the options on top.

[fuzzel]

rev3723 is up:

 

- show kicker's orientation in the editor
 

[Slydog43]

If 10.6 is almost ready, will 10.7 be next or will there be a larger jump to 11 or something?  What are the devs thinking?

[fuzzel]

Good question. At the moment I have not really much time for VP so any long term development is not really an option at the moment. On the other side I would like to do the next big thing and implement free camera movement, a mesh manager with a mesh preview feature and all the other things that might break compatibility. But all this needs time and as said is really limited at the moment.

[bord]

Good question. At the moment I have not really much time for VP so any long term development is not really an option at the moment. On the other side I would like to do the next big thing and implement free camera movement, a mesh manager with a mesh preview feature and all the other things that might break compatibility. But all this needs time and as said is really limited at the moment.

 

All that you do in development with limited time is much appreciated. Looking forward to whenever you get to go after your goals and break compatibility. Break away!

[flupper1]

I have a question or maybe an issue to report (depending on whether I am doing something wrong or there is an issue):

I have problems getting the normal maps to work properly. On the Totan lamp the normalmap I made looks like this in VPX (without ornaments, just highpoly lamp baked normals to lowpoly lamp):

Notice especially the blocky effects on the top, just above the flat part of the lamp.

 

It should resemble something like this:

However, if in Blender I change the "image file color space" (in the image node on the left) to "color" (instead of non color), it looks like this:

And this looks like what is happening in VPX.  Blenders description of this color vs non-color data is: with color "the image will be converted to linear color for rendering".

So, either I am doing something wrong or there might be something in the VPX code which causes this (my guess then would be something with the colorspace either images are imported in or converted during rendering).

 

The stuff I tried:

- I baked normals with xnormal, same result as with blender

- I changed the +X and +Y and +Z to variations of -X, -Y, -Z when baking

- I imported some models from Dark with normals, they seem to have the same problem

- imported with different file formats

What am I missing when using a normal map? Or is there something in the code?

[bord]

However, if in Blender I change the "image file color space" (in the image node on the left) to "color" (instead of non color), it looks like this:

And this looks like what is happening in VPX.  Blenders description of this color vs non-color data is: with color "the image will be converted to linear color for rendering".

So, either I am doing something wrong or there might be something in the VPX code which causes this (my guess then would be something with the colorspace either images are imported in or converted during rendering).

 

Almost looks like with a normal map applied VP is ignoring the shade smooth flag on the mesh.

[toxie]

Good question. At the moment I have not really much time for VP so any long term development is not really an option at the moment. On the other side I would like to do the next big thing and implement free camera movement, a mesh manager with a mesh preview feature and all the other things that might break compatibility. But all this needs time and as said is really limited at the moment.

 

Same for me. Dynamic/'Real' lighting would be one of the things to tackle for me. And/Or introduce ray tracing, even if its only for ultra high end cards at the moment.

 

But at least with Caligula and VPVR we have somebody that already pushes into the right direction. Lets see how we can combine all the efforts in the future.

[kiwi]

Perhaps the value that the plunger returns is a bit low (position from 0 to 25),

I don't have a fluid movement if I move a mesh, if you could have a higher value like 0 to 250, or what is more convenient.

 

Thanks!

[Caligula_]

 

Good question. At the moment I have not really much time for VP so any long term development is not really an option at the moment. On the other side I would like to do the next big thing and implement free camera movement, a mesh manager with a mesh preview feature and all the other things that might break compatibility. But all this needs time and as said is really limited at the moment.

 

Same for me. Dynamic/'Real' lighting would be one of the things to tackle for me. And/Or introduce ray tracing, even if its only for ultra high end cards at the moment.

 

But at least with Caligula and VPVR we have somebody that already pushes into the right direction. Lets see how we can combine all the efforts in the future.

 

 

Raytracing would be a nice feature, but for that VPX would need to upgrade to Vulkan or DX12. And this would probably more complex than switching to OpenGL. Maybe we could ask Christoph Schied who did the Quake 2 port to RTX if we could use his part of the code (we have to ask him, because his code is under GPL which is incompatible to the VP license). But even if we get his permission someone would have to do the port. Another solution would be the usage of a game engine. This would mean a lot of porting effort (since we probably have to port not only the rendering part, but also the editor, the loader, the phyics engine, the sound engine...) and might also be complicated from license point of view, but on long term we could focus more on the pinball part and also porting Visual Pinball to new plattforms would be easier.

[blindpeser]

 

Good question. At the moment I have not really much time for VP so any long term development is not really an option at the moment. On the other side I would like to do the next big thing and implement free camera movement, a mesh manager with a mesh preview feature and all the other things that might break compatibility. But all this needs time and as said is really limited at the moment.

 
Same for me. Dynamic/'Real' lighting would be one of the things to tackle for me. And/Or introduce ray tracing, even if its only for ultra high end cards at the moment.
 
But at least with Caligula and VPVR we have somebody that already pushes into the right direction. Lets see how we can combine all the efforts in the future.
 

 
Raytracing would be a nice feature, but for that VPX would need to upgrade to Vulkan or DX12. And this would probably more complex than switching to OpenGL. Maybe we could ask Christoph Schied who did the Quake 2 port to RTX if we could use his part of the code (we have to ask him, because his code is under GPL which is incompatible to the VP license). But even if we get his permission someone would have to do the port. Another solution would be the usage of a game engine. This would mean a lot of porting effort (since we probably have to port not only the rendering part, but also the editor, the loader, the phyics engine, the sound engine...) and might also be complicated from license point of view, but on long term we could focus more on the pinball part and also porting Visual Pinball to new plattforms would be easier.

Other platforms? Sounds amazing! When does the porting start?

[Rawnei]

Maybe OpenGL will get ray-tracing extensions, it's not impossible that khronos group is working on that, maybe ATI will release RT hardware and compete with Nvidia bringing prices down making it a more common thing and not just for high-end rigs, I'm interested to see where ATI's new architecture will be positioned in terms of ray-tracing, I mean ATI chips are in both PS5 and Xbox Scarlett and those will have Ray-tracing support so competition is around the corner.

 

 

Other platforms? Sounds amazing! When does the porting start?

 

This is a pretty counterproductive comment, the main point is that it's a big undertaking and saying things like this is dismissing the effort that is required.

[blindpeser]

Maybe OpenGL will get ray-tracing extensions, it's not impossible that khronos group is working on that, maybe ATI will release RT hardware and compete with Nvidia bringing prices down making it a more common thing and not just for high-end rigs, I'm interested to see where ATI's new architecture will be positioned in terms of ray-tracing, I mean ATI chips are in both PS5 and Xbox Scarlett and those will have Ray-tracing support so competition is around the corner.
 

 Other platforms? Sounds amazing! When does the porting start?

 
This is a pretty counterproductive comment, the main point is that it's a big undertaking and saying things like this is dismissing the effort that is required.

I think everybody got that this was a joke.

[cyberpez]

2 requests...  Would it be possible to make flippers collidable non-collidable via the script?  Second..  I love exporting the table to obj to check the placement of things..  could there be an option to export collidable objects only? (even if hidden)  Also maybe an option to export flashers, even if just a big square would be great....  Thanks!!

[32assassin]

if their is an official release near by

can you update this ( the All in on installer needs to include this)

 

https://www.vpforums...s&showfile=1362

 

to include

 

freddy4 -  Freddy:A Nightmare on Elm Street (rev.4)

stargat5 - Stargate (rev.5)

sfight2b - Street Fighter II (rev. 2) Color Project exists for this rom version

smb1 - Super Mario (rev. 1)

smb2 - Super Mario (rev. 2)

smb3 - Super Mario (rev. 3) Color Project exists for this rom version

teedoff1 - Teed Off (rev.1)

teedoff3 - Teed Off (rev.3)

 

 

and I'm not 100% certain but I think this also needs to be added

snspares1 - Strikes N' Spares (rev. 1)

snspares2 - Strikes N' Spares (rev. 2)

snspares - Strikes N' Spares (rev. 6)

[ClarkKent]

I wonder if VPX could be using inch/mm instead of the weird VP-units in a future version. Using the VP-units makes no sense anymore. Building tables in actual size would be much more exact and less confusing.

[ClarkKent]

For the moment the transition to inch/mm would be enough...

[toxie]

 

 

Good question. At the moment I have not really much time for VP so any long term development is not really an option at the moment. On the other side I would like to do the next big thing and implement free camera movement, a mesh manager with a mesh preview feature and all the other things that might break compatibility. But all this needs time and as said is really limited at the moment.

 

Same for me. Dynamic/'Real' lighting would be one of the things to tackle for me. And/Or introduce ray tracing, even if its only for ultra high end cards at the moment.

 

But at least with Caligula and VPVR we have somebody that already pushes into the right direction. Lets see how we can combine all the efforts in the future.

 

 

Raytracing would be a nice feature, but for that VPX would need to upgrade to Vulkan or DX12. And this would probably more complex than switching to OpenGL. Maybe we could ask Christoph Schied who did the Quake 2 port to RTX if we could use his part of the code (we have to ask him, because his code is under GPL which is incompatible to the VP license). But even if we get his permission someone would have to do the port. Another solution would be the usage of a game engine. This would mean a lot of porting effort (since we probably have to port not only the rendering part, but also the editor, the loader, the phyics engine, the sound engine...) and might also be complicated from license point of view, but on long term we could focus more on the pinball part and also porting Visual Pinball to new plattforms would be easier.

 

 

Asking Christoph would be the easy part, as i know him pretty well. We could also go for a interop solution and only trace rays via vulkan, and do the rest via GL. At the moment this seems to be the fastest solution to drive RT cores anyway (i.e. not much shading done via closest/any hit programs, but doing that in separate progs similar to deferred rendering).

 

I'm personally against using a game engine, as the main fun i have contributing to VPX is that i have full control over everything, which also can pay off, one prominent example being the split into static and dynamic rendering that we use nowadays. Similar things could be done when going full dynamic lighting as most of the table is still static geometry all the time, so the tricks to get high quality lighting can vary a lot from games.

Plus one not only gets all the goods but also all the bads from using such a huge thingie.

Maybe OpenGL will get ray-tracing extensions, it's not impossible that khronos group is working on that, maybe ATI will release RT hardware and compete with Nvidia bringing prices down making it a more common thing and not just for high-end rigs, I'm interested to see where ATI's new architecture will be positioned in terms of ray-tracing, I mean ATI chips are in both PS5 and Xbox Scarlett and those will have Ray-tracing support so competition is around the corner.

 

To all my knowledge there is no support planned for GL at the moment. Also Xbox will obviously be DX based again, and PS5 may use something Sony exclusive again i'd guess (similar to PS4).