813 replies to this topic

[jsm174]

You don't necessarily have to clone the repo (all though it's easier to keep up to date if you do).

 

You can always just download the zip:

 

[freezy]

Download is fine but a hassle when you want to update quickly. The git cheat sheet would be:

 

Clone into a new folder:

• git clone https://github.com/f...ball.Engine.git

Update to latest (and destroy all changes)

• cd \path\to\VisualPinball.Engine
• git fetch --prune
• git reset --hard origin/master

By the way I've just merged a huge PR (the one with the toolbox), so you guys should probably upgrade

[DJRobX]

Thing about real-time lighting is that we firstly need to get the setup right. Lights will work differently as in VP, for example a GI bulb, which is a point light, is modeled differently than an insert or a flasher. So we firstly need to identify which is which (VP doesn't distinguish between an insert and a GI light), and then we need to find a good way to simulate inserts. For the flashers, we also need to find a way to position them correctly, because in VP there's currently no way of determining the flasher's light source in 3D space. These are all data-related issues that we'd like to solve as automated as possible, once we have that we can dive into how to actually render them. So a few things to do before you get so see light shows (also, PinMAME integration would be useful at some point in order to test).

VPX doesn't actually integrate with vpinmame.    Vpinmame integration is a byproduct of its vbscript support.   So to get the mappings we need vbscript support.

Core scripts do support using the timer interval variable to automatically wire up a lamp ID to a light, but it's rarely used. 

[TerryRed]

Interesting timing talking about lighting and point lights, etc. This is probably the one thing I'm most excited about with VPE.

 

With FP-BAM, we've always had "real-time lighting" with point lights which were called "hardware lights" which by default are used as flashers. With FP's old native lighting it was restricted as was the global lighting. BAM can along and changed everything to allow not only per-pixel lighting and rendering from those point lights / flashers.... but also the ability to control every aspect of all lights (among a million other features).

 

Even though these lights are "flashers", in the last year or so, we started to used them as the G.I which makes a huge difference in how a FP table looks today compared to even a year ago. I would just use a small nano flasher model and hide it in the slingshots or other plastics. 2 or 3 of these points lights were enough for most tables and looked great.

 

Well "today" much has changed again with a new (wip) update to BAM to allow for "real-time lighting" with spot lights! This is a huge change and can make a big difference to lighting.

 

I bring this up because we haven't seen much yet with lighting on VPE (except for the excellent videos on the first page). I do have a video demo showing you how real spot lights can look with a FP table and how it affects the normal mapping and the other table elements. 

 

Note: in the video most of the table lights (GI, some inserts, etc) are OFF for this demo to make it easier to see just how "real" this lighting is (no realtime shadows, obviously).

 

You can adjust the falloff, the rotation, the angles, brightness, colour,etc... and as the video shows, you can use BAM's mini playfield tool to move the lighting anywhere you want for animations.

 

I can't even imagine what will be possible with VPE.

 

 

https://youtu.be/ANQgD3kIEUc

 

 

 

 

This isn't me trying to hi-jack a VPE thread with a FP video... I just get SOOO excited about lighting!

 

 

As for flashers... I know you want to automate as much as possible with importing / converting a VPX table... but really... most tables only have 5 to 10 flashers at most. That shouldn't be a difficult thing to add on the VPE side manually, especially with an amazing 3d editor. Chances are, the author will be doing that anyway to make the table look better or the way they want.

 

Maybe the mesh for the flasher on the table could be re-named something to act as a tag of some sort, specifically just for the purpose of importing into VPE. If it can get the position data of the mesh like other parts of the table, only in this case VPE would recognise it as a flasher based on it's name... then wouldn't that be close enough? Maybe the same idea for GI bulbs,etc?

Edited by TerryRed, 19 August 2020 - 06:06 AM.

[hitman2304]

This is amazing. I hope such talented developer as You will start making tables for VPE. 

Edited by hitman2304, 19 August 2020 - 07:02 AM.

[TerryRed]

This is amazing. I hope such talented developer as You will start making tables for VPE.

 

 

ravaracade is the talent making that possible. I just like lots of lights and bling and like to use it creatively wherever I can. Not always "realistically"... but fun for me.

 

...but yes when VPE is a complete product that can support not only rom based tables...but original tables with a similar (and probably better) toolset that I can use now (with some great examples to learn from).... I can't wait to jump in. I'm like everyone else... just drooling at any progress I see in this thread.

Edited by TerryRed, 19 August 2020 - 06:55 AM.

[freezy]

VPX doesn't actually integrate with vpinmame.    Vpinmame integration is a byproduct of its vbscript support.   So to get the mappings we need vbscript support.

Core scripts do support using the timer interval variable to automatically wire up a lamp ID to a light, but it's rarely used.

 

Yes but we're not developing VPX are we

I really want to have a "batteries included" approach with VPE. Meaning if you want to use PinMAME, you shouldn't have to install it, instantiate a COM bridge in your script and use its polling API. For PinMAME, I would see more like a component you stick on your table and in the editor you visually link your game items to the ROM's switches, lamps and coils. Same with MPF by the way, but that's a discussion for another day

 

@TerryRed: Sorry for the lack of lighting shots. I basically did some tests at the very beginning of the project, was happy with it, and moved on implementing the foundations. So just placing a light source and turning it on and off in the editor is done, the next step would be having them driven by a ROM, and that needs some more things done as mentioned above.

 

I'm not sure I follow with your flasher mesh proposal above. Technically a light isn't a mesh, even if it's often inside a mesh, like a bulb or a flasher dome. The meshes we are able to handle correctly, it's just the light source that will probably need manual alignment (and we can easily identify flashers, they are a separate game item type), but as you said, there aren't dozens of flashers in a game, and for the GI we're more or less okay. The only thing we need to figure out still are the inserts.

[blindpeser]

@TerryRed: This looks amazing. Rafal is the mastermind behind this, right? I hope he is still on board for VPE. If he is, I am even more excited about all the genius stuff freezy and the gang are baking for us. Thanks guys!

[hitman2304]

Ravarcade/Rafal Janicki is in VPE development team as contributor 

[TerryRed]

 

VPX doesn't actually integrate with vpinmame.    Vpinmame integration is a byproduct of its vbscript support.   So to get the mappings we need vbscript support.

Core scripts do support using the timer interval variable to automatically wire up a lamp ID to a light, but it's rarely used.

 

Yes but we're not developing VPX are we

I really want to have a "batteries included" approach with VPE. Meaning if you want to use PinMAME, you shouldn't have to install it, instantiate a COM bridge in your script and use its polling API. For PinMAME, I would see more like a component you stick on your table and in the editor you visually link your game items to the ROM's switches, lamps and coils. Same with MPF by the way, but that's a discussion for another day

 

@TerryRed: Sorry for the lack of lighting shots. I basically did some tests at the very beginning of the project, was happy with it, and moved on implementing the foundations. So just placing a light source and turning it on and off in the editor is done, the next step would be having them driven by a ROM, and that needs some more things done as mentioned above.

 

I'm not sure I follow with your flasher mesh proposal above. Technically a light isn't a mesh, even if it's often inside a mesh, like a bulb or a flasher dome. The meshes we are able to handle correctly, it's just the light source that will probably need manual alignment (and we can easily identify flashers, they are a separate game item type), but as you said, there aren't dozens of flashers in a game, and for the GI we're more or less okay. The only thing we need to figure out still are the inserts.

 

 

 

My thought was just to use the mesh itself as a means to create a flasher on the VPE side is all I meant. The idea being that you could just name the mesh something specific, then VPE would not only import the mesh, but automatically create a flasher in that space since it has a specific name (to tell VPE to do so). That's all.

 

PLEASE... don't apologise for not having any lighting demos! I only meant we haven't seen any videos yet...not... "Where are they?!?!" (using my best Batman voice).

 

I just posted the video and explained a little background about lighting for those who never knew the differences with FP-BAM and how "point-lights" work, and my new excitement for being able to use spot lights. The video gives a glimpse of what VPE lighting can be capable of. It's going to be great!

 

I know this stuff takes long time and a crap load of work,as does everyone. We all know this...and I'm very realistic about the time it will take to reach certain milestones. You guys will get there! It's amazing what we've seen so far!

[waynewhitney]

I just started testing this on some existing tables today, and i have a couple questions. I notice some similarities to the Blender interface. When rotating an object, (as in Blender) the CTRL key restrains the rotation to 5 degree increments. Is there a visual indication of the number of degrees rotated?

When zooming in, is there a way to stop the view from clipping? I can't seem to get in close enough before it renders the object I'm trying to look at transparent.

When moving objects along x, y or z axis, is there a way to do micro moves (other than typing in small changes numerically?)

[freezy]

https://docs.unity3d...Navigation.html

 

Speed can be regulated with the mouse wheel while flying. About clipping, try not to zoom but to fly closer instead, that usually helps. About micro moves I don't know, did you try the usual suspects (ctrl, alt, shift, combination of those)? Doesn't zooming in also help?

[waynewhitney]

https://docs.unity3d...Navigation.html

 

Speed can be regulated with the mouse wheel while flying. About clipping, try not to zoom but to fly closer instead, that usually helps. About micro moves I don't know, did you try the usual suspects (ctrl, alt, shift, combination of those)? Doesn't zooming in also help?

Zooming in works to a certain point, then the selected object becomes transparent. I'm guessing that when a VPX file is opened, any flasher objects are ignored and not imported. Have tried several tables and no flashers yet.

This thing is amazing to use! I've been building cabs in VR with the old editor. This is MUCH less painful for tweaking the positions of things like rails and coin doors!

[freezy]

All game items are imported, the only things you'll currently lose when exporting are fonts and animated meshes. Flashers are imported (and exported), but they don't appear in the hierarchy yet, because we yet have to deal with how we render them. So you can't change their props, but they will be exported as they were imported (along with other non-visible stuff like timers, decals, light sequences, collections, etc).

[waynewhitney]

All game items are imported, the only things you'll currently lose when exporting are fonts and animated meshes. Flashers are imported (and exported), but they don't appear in the hierarchy yet, because we yet have to deal with how we render them. So you can't change their props, but they will be exported as they were imported (along with other non-visible stuff like timers, decals, light sequences, collections, etc).

Thanks for that info! I'm very excited about this advancement!

One more question: Is there a size limit to the tables? I'll use a very recent table as an example: GOTG.

When this is imported it comes in with no playfield.

I also tried Rocky and Bullwinkle. That one came in with some of its wire ramps missing.

On the other hand, Bubba The Redneck Werewolf came in absolutely complete! 

One more question! 

Will it be possible to load 2 tables and copy/paste elements between them?

[freezy]

Glad to hear!

 

For the size, the only issue I've encountered is this one, but that should completely crash. If it runs through but stuff is missing, I'd like to ask you for a repro use case so we can debug it.

 

In terms of copy/paste, yes, it's a feature, but needs to be implemented first.

[waynewhitney]

What do you need specifically, regarding the tables with missing elements?

[freezy]

Link to the table and which element is missing exactly would help! It's already missing on import, right?

[waynewhitney]

Yes. There are a couple tables where things like Rubbers are radically re positioned on the Z axis as well.

[freezy]

Oh, okay. If you're on GitHub, an issue would be easier for us without pestering everybody in here