Jump to content

freezy

VIP Class
  • Posts

    174
  • Joined

  • Last visited

  • Days Won

    10

freezy last won the day on July 3 2018

freezy had the most liked content!

3 Followers

About freezy

Profile Information

  • Gender
    Female

Recent Profile Visitors

2,245 profile views

freezy's Achievements

Enthusiast

Enthusiast (6/14)

  • Reacting Well
  • Very Popular
  • Dedicated
  • Conversation Starter
  • First Post

Recent Badges

218

Reputation

  1. First of all, apologies to anyone who was playing around with VPE in the last six weeks, most of the features were utterly broken due to the last refactoring. I've just merged a branch with fixes and further refactoring, and after more extensive testing I'm pretty happy now, mainly because I can move on to more innovative stuff. Here are the changes, apologies for being a bit technical this time. Prefabs Prefabs in Unity allow you to create re-usable blocks where you can override things and even create variants. So what we're doing now during VPX import is setting up a scene like you would if you were doing it manually: Every game item is instantiated from a prefab that we actually ship (we used to create prefabs on the fly before). Game items of the same type inherit all from the same prefab (before, we created a new prefab for each game item on the playfield). We use prefab variants where it makes sense. For example, the various gate types are all variations of the same prefab. All in all I think it's an awesome approach. I see prefabs being used in the future all over the place. Think of a library of ready-to-use elements like pegs, flippers from all eras with primitives already set up, etc etc. There's also another aspect, which is performance. When using prefabs, Unity knows which elements on the screen are the same, and can thus reduce draw calls. For example, if we were to provide a screw prefab, you could place as many as you want in the scene without having to manually merge them into a big mesh to gain performance. More flexibility at no cost! Data This was mainly addressed in the last refactoring, but even more improved in this one. What we did originally was read the entire VPX file into data classes and store them in the scene. This was awfully slow because meshes, textures and sounds were serialized in a format similar to JSON, which was very inefficient. Then, we cleared out the heavy stuff and saved it directly on the file system, but still used the data classes as the "source of truth". Now, there are no data classes in the scene anymore. We copy the relevant fields to the Unity components during import and copy them back during export, but the source of truth are the components now. This opened a whole new world of editor features, since we can now use Unity like we're supposed to. For example, when you put a bumper on a surface, we reference that surface so we can calculate the height of the bumper. Via data objects, this reference was done by surface name, so we needed to maintain a list of surfaces by name to find the right surface, renaming the surface broke the reference, and you couldn't have multiple surfaces with the same name. Now, we just reference the component and that's it. Rename the wall, and it will be updated automatically in the bumper referencing it. Remove it from the scene and it'll be unset, not crashing due to missing references and all the other things you need to deal with when you manually handle references. Also, we can now update everything in real-time now. Check this out: Finally, we only copy fields that are relevant for VPE, which makes the code much more clear to read. Everything in the component has a purpose, which is cool. Wiring As you know, you can visually wire PinMAME inputs and outputs to the playfield items. Until now, these items could either support one switch/coil/light, or act as a "device", with multiple switches/coils/lights. For example, the trough has one or two coils depending on the type, and a switch for each ball. There is also the "Wire Manager" where you can link up outputs (switches) directly to inputs (coils and lamps). Anyway, it doesn't make much sense technically to distinguish between "has one coil" and "has one or more coils". So all game items now always support multiple inputs and outputs. Which simplifies a lot of stuff, actually. If you have a game in MPF that relies on dual-wound coils, just tick "dual wound" in the flipper's inspector and you'll get two coil inputs to link up. It's all much more natural now. Another example are kickers. Some kickers have multiple coils for kicking out the ball at different directions. In VPE, you choose direction, force and inclination in the inspector for each coil, and off you go with multi-coil kickers. Export So, we're moving a bit away from the VPE-as-VPX-editor approach, meaning while you still can export your table, VPE won't be covering all your VPX editor needs. This is specially true for materials, since materials are very specific to the renderer, which is different from VPX. When importing, VPX materials are converted to the current render pipeline's Unity material, but they aren't converted back. This PR removed the material editor. You can't visualize VPX materials in VPE anyway, VPX materials are just converted but not referenced in any way once you start tweaking them. Other Changes There were a few other things I've tackled on the way: In VPX, you can globally scale the entire table along the Z axis (depending on the POV). This was removed, since we should be able to achieve the same results with Unity's camera settings. Custom playfield meshes are now fully supported! Just uncheck the playfield's default mesh option and drag your mesh into the mesh field. We now distinguish between the "table" and the "playfield". So a few attributes like dimensions and slope angle etc moved from table to the playfield, and the children retrieve these values from their first parent. This should make it less difficult to support multiple playfields in the future. Editing drag points for walls, ramps, triggers & co is now always enabled. Drop targets and hit targets are two different components now. Collider rendering in the scene view has been revamped. It uses proper meshes now, and they are cached, so you can render them all at once if you're debugging where your ball is stuck. If you know that an item like a rubber won't ever be used as collider, you can now remove the collider component and it will not be added to the physics world (like a primitive toy), resulting in better performance. The boundaries of the flipper are now more precisely computed, meaning the physics code won't try to collide against the flipper when the ball is still in the lane (look at the pink box in the video). Finally, we might have a new logo! Thanks to everybody who commented. That's it for now -freezy.
  2. So, we've noticed a few bugs with the last refactoring. It's about prefabs and how they are currently used. I'll be working on that next. Meanwhile I've removed the Hybrid Renderer, meaning VPE will be using the render pipeline's default renderer. This has a few advantages: The default renderers are more stable and feature rich (i.e. we can now use DXR again and a few other things we couldn't before, namely skinned meshes). Code is simpler overall, since we don't have to deal with DOTS' parenting The established debugging tools for the scene work again, so you can pause the game and inspect all items instead of having to rely on the clunky Entities Debugger. I've also tested Unity's 2021.2 beta and it seems to work well (DOTS is supposed to be incompatible with anything but 2020.3). This is awesome because it provides even more features like DLSS on NVidia cards, many editor improvements, deferred rendering on URP and few more things. Anyway, if you want to take it for a spin, it's v0.0.1-preview.53 for URP and v0.0.1-preview.74 for HDRP. Be aware though, as mentioned above, prefabs are still buggy (you can't currently change props without explicitly editing the prefab).
  3. Please fastdraw aka fripounet aka granit aka hotdog aka whateverthefuckyoucallyourselftomorrow, can you leave my thread in peace please?
  4. The goal of the export is not to convert VPE tables into VPX tables no matter what. It's a convenient way of editing existing VPX tables. You get a nice 3D editor and IMO better tooling to get stuff done. But of course you can't really script anything, or debug table logic, because that's VPX-specific.
  5. Yeah that's a good question. @BilboX already takes the piss out of me for insisting on VPX export. The idea of VPX export is still to get VPX creators to take it for a spin without having to completely switch engines, i.e. allow a smoother transition. But I see that getting VPX creators onboard might not be such a problem after all. It's not holding anything back though. It's more effort, but it's separated from the rest. If at some point it doesn't make sense anymore to maintain this feature, so be it. It's certainly not hindering innovations or getting new tech into VPE.
  6. Small Update. Finally, after over three months of refactoring, I've merged a branch of 8k lines which changes the way a table is loaded into the Unity editor. This part was the first thing I implemented when I had no clue about how Unity works, and it was done in a, uh, sub optimal way. Details are here. The short version is that instead of keeping the original structure of the VPX file intact and serializing it as one giant blob, we now extract all media, meshes, textures, materials etc into separate files so they are part of Unity's asset database. This allows for faster start-up, and you can easily edit your assets. However, importing the table into the editor takes longer, because all the assets are now loaded analyzed by Unity. Re-importing a table whose assets are already on disk is nearly instant though. For those of you who already started playing around with VPE, you'll need to re-import your table again. This will probably happen a few more times until we become stable enough to start thinking about migrations. Another improvement was editor speed. We added some hacks to provide a better editor experience, which turned out to be quite expensive. They are all gone now. You can upgrade by opening the Package Manager, select Visual Pinball (HDRP), and hit "Upgrade". Latest version is v0.0.1-preview.72. Next thing I'll be working on is ditching the Hybrid Renderer, which gives us access to more features and stability, as well as re-organizing and updating documentation. Apologies for not having something more sexy to present, but well, the foundations of the code base are important too, right
  7. Neither, it was the CI (AppVeyor) that reduced the life time of the build artifacts from six months to one. But as Terry said, it's released and you grab it from GitHub now.
  8. Hi! So, it has come to my attention that people are sharing dmdext through Dropbox because Appveyor decided to shorten the life time of their artifacts. So, time for a new official release, maybe? As usual, you'll find it here. There are two main features: Better DMD rendering on monitors (thanks @vbousquet) Support for Future Pinball (thanks @MrMoose74) If you're into FP, check out Terry's guide. @TerryRed please update the download link in your article. If you're into customizing the look of your virtual DMD, check out this thread at VPF. Thanks to @Wiesshund and @dcbenji for the awesome styles, they're included in the release. Enjoy!
  9. You're aware that posts get read more often that written, right? So 100 people having to manually translate shit as opposed to the poster doing it once sounds okay to you? Not everybody is using Google Chrome.
  10. Again, you're missing the part where the community platform is not the same as the download platform.
  11. I did that with vpdb.io a few years ago. Fully API driven, structured data, plus a nice UI. But it's hard to convince authors to publish to a site outside of their actual community. It's cool tech, but tech is only half of the picture. You also need people, the community, and the community is here at the forums, which are primarily made for that. Of course nothing would prevent someone to do both, and afaik Dazz is looking for a coder, but it will take time and unfortunately I can't clone myself.
  12. Well, rendering and audio have their own thread in Unity. But when it comes to code in general, there is no such thing as "out of the box" handling of multi core programming. Unity has awesome support for multithreading, but you have to structure your code and logic in a way it's actually possible to run on multiple cores. And the way the physics simulation works, it's actually quite hard to do. We might be able process ball collisions for multiple balls in parallel, but otherwise it's not trivial. Additionally, scheduling code on another core is not for free, so if you're doing it 1000 times per second it can become a bottleneck as well. So there are a few things we can do, but don't expect miracles.
  13. @KRougeI think you've misunderstood the point about the repositories. There's never going to be a single repo with all tables that you can just pull from. The VCS-friendly format is the authoring format, not the format in which tables are shared between players. So I'm sorry but you'll still going to have to go visit the release threads or individual repos if you want to stay up to date. @scottacusDon't spend too much time on lighting yet. We barely have a physical setup that works well, let alone all the logic part worked out. Flashers aren't even imported yet.
  14. Yeah sorry context switching is hard, I'm taking regular timeouts from VPE to work on dmdext, but right now I need to finish some other things first. @DJRobX would be able to work on it too, if he has some time to spare.
  15. No worries. Yes, without VPE specific tables appearing, the whole exercise would be kind of useless. However I don't worry too much about creators not adapting VPE, since we're working together with them on many things.
×
×
  • Create New...