Announcement

Collapse
No announcement yet.

Map Scaler [Blueprint][Editor]

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Okay thanks for the info.

    Leave a comment:


  • replied
    Originally posted by MΛuL View Post
    Hey Rattle, does this need to be updated for the 4.14 update?
    Not sure, I haven't opened/tested the MapScaler asset so far (dev or the public release). I have been updating the other stuff before. In general Blueprint assets should work fine with every engine update unless Blueprint and the API heavily change (but they might convert old code to newer code automatically). The MapScaler plugin needs an update though.

    Leave a comment:


  • replied
    Hey Rattle, does this need to be updated for the 4.14 update?

    Leave a comment:


  • replied
    Thanks for continuing to work on this Rattle!

    Leave a comment:


  • replied
    Quick heads-up.

    1.5 will come. ETA 2 weeks (more or less; I'm not that good at judging how long it takes working on the massive Single-Blueprint and testing each single case several times). I still have about 15 minor or major features/issues/changes for the upcoming version where it already has 21 changes (changelog). I do already have most of things fixed what has been reported here. The upcoming version will have several features added which allows a quite perfect scaled map (depending what options you've selected and I'm aware what has to be scaled). Same as v1.4, the upcoming version will heavily (even more) rely on the C++ plugin. It is required to get access to some properties/code Blueprint doesn't have access to. And it even optmizes the process (for instance the Runaway loop prevention), There's no other way 'round that, sadly.
    (Just an example, scaling DM-Outpost23 will crash the Blueprint VM and abort the scaling process. This is originated in how Blueprint code is processed and prevented to run forever for a single call. Due to the way the MapScaler can be setup and is designed, it will process a ton of nodes the more Actors are in a map. I generally try to work around these issues automatically (using C++, Blueprint hacks, config changes explained in readme, etc.) but there is no proper way to catch such issues (although I plan to do so in pure BP)).

    In mean time, in case anyone has to offer advice or reports of issues or things which have to be scaled as well, please, feel free to post it. Also, in case anyone has taken a look on the actual Blueprint code of the MapScaler, feel free to correct me and my code in case you see a problem (and report back). Some things were initially done and I already regret having done it that way (e.g. Macros, Collapsed Nodes, global temp vars, etc.) but for some things there is a specific reason (e.g. multiple vars for structs, sequential Find instead of ForLoop, etc.).


    PS: Since the native plugin in version 1.4 is outdated for a long time (I'm not even sure if it's built with the same core engine), you guys likely didn't use it or being able to use it (unless you modified the API version of the plugin). With the following version, I will (likely) release a small tool to tweak a/the plugin to be ready for each upcoming UT build (as long as the major engine version stays the same, otherwise it is not guaranteed it will work). This way anyone can simply adjust the DLL and keep using it. instead of having to wait until a new version is released. By the release of the next version, I try to keep the interval short or even try to release the re-compiled native plugin without any changes to the MapScaler asset, no guarantee. If I manage to implement all TODOs, I don't have plans with MapScaler anymore other than a complete rewritten tool or ported one to be C++ only.

    Leave a comment:


  • replied
    Originally posted by BloodK1nG View Post
    Hahhhhhhhhhhhhhhhhhhhhhhhh finally understood why MapScaler was doing a big mess in maps Your tool dont like when I attach mesh between them... but I need to attach them
    You mean having meshes attached to something? It is a known problem nowdays which I didn't know for a long time (and haven't done anything regarding that). Therefore, the desired scale is applied twice, one time via the MapScaler directly and the 2nd time natively by the engine when the parent actor is scaled.

    The problem has been fixed in my current MapScaler code but I lost track of UT, and the interest in UT (and sadly even the faith in it). Therefore I haven't got the time/mood to finish the next version of the MapScaler (when it was requested). I still don't know when or if...
    Last edited by RattleSN4K3; 09-15-2016, 10:01 AM.

    Leave a comment:


  • replied
    Hahhhhhhhhhhhhhhhhhhhhhhhh finally understood why MapScaler was doing a big mess in maps Your tool dont like when I attach mesh between them... but I need to attach them

    Leave a comment:


  • replied
    [MENTION=7664]G.Lecter[/MENTION]
    Camera Bookmarks is possible. However, it requires native support. I am not able to read Static Array from Blueprint (I haven't tested it, but compiles exposed StaticArrays isn't working).

    Seems like either v1.4 and/or my current dev version is buggy. By scaling the level more than once (sequentially), the reverting process doesn't properly restore some props (noticed it with the new ReflectionCapture influence Radius); using undo mutliple times instead works just fine. Additionally to that by using UNDO, some data might still be stored after every step is undone (noticed SkyLights data and ReflectionCapture data). Must be a copy and paste problem as copy-paste is not that simple to do in Blueprint (e.g. you still need to connect nodes to external nodes/pins you didn't copy).

    Leave a comment:


  • replied
    Originally posted by RattleSN4K3 View Post
    That last sunday, no . Hopefully I can get version out this sunday/week.
    I have scaled my level down with the non-plugin version already. My lights and stuff are quite well organised in the World Outliner so scaling them down manually didn't turn out to be as much work as I thought... I dunno if there are other Mapcore candidates that would need to use this tool, though...

    If I programmatically change the influence radius and rebuild everything/lightning, the sphere reflection visual presentation in editor does update once it is finished. I still support the native support as it updates immediately.
    Something you may want to keep in mind regarding reflections: When I scaled my reflection radiuses manually, the editor lagged horribly and it took it ~half a minute to edit each one of my values. I think this happened because I had scaled my lights down first and the editor does not like to do stuff when you have unbuilt lights. I dunno if the order you scale things affects the MapScaler performance or not but, if it does, you really want to scale reflections first and then scale the light radiuses. Updating the captures when you have a lot of lights that need to be rebuilt sounds useless to me...

    It doesn't (in case you mean "Cull Distances" in a CullDistanceVolume actor). Thanks for that. I could have find it when I would be about testing several other common Actor types. Haven't got the time to do so.
    Yeah, I was thinking mostly about CullDistanceVolumes, but there are also some DrawDistance settings in the StaticMesh properties you may want to look at.

    Finally, if you want to be super-picky, I came across one last thing that could be scaled too: Camera Bookmarks! These don't appear as placeable actors in the map, but perhaps there's something you can do with them...

    Good to hear you're making progress!
    Last edited by TheGlecter; 06-29-2016, 08:46 AM.

    Leave a comment:


  • replied
    Originally posted by G.Lecter View Post
    So, won't a plugin version be ready for MapCore? My level is pretty much finished at this point and I'm going to scale it down on Sunday or so... Like I said before, I can live without the plugin but I would really appreciate having it if possible...
    That last sunday, no . Hopefully I can get version out this sunday/week. Actually, I was planning a lot of changes to this/a new version. It's not only the new scaling things but some things to improve the use of it. I'm still not keen on they way I have to reference Actors in the Blueprint. This is resulting into the delete message if you remove an actor if you've placed a MapScaler in the world. There is a proper way to reference these actors, but you're not able to use/create it in Blueprint code. I'll investigate if an approach of using C++ code to create/generate such weak references and store these instead. The problem with that seems obvious, a non-native-supported MapScaler should be able to read the data from a native-supported one (and vice versa). This results into having multiple arrays for just this purpose whereever I use an Actor type property. And this is a lot. This could bloat the MapScaler alot. Keep asking myself why it isn't possible from the engine standpoint...

    Originally posted by G.Lecter View Post
    Reflections are automatically updated when you build lighting too. You might not need any specific code for that.
    Seems to be the case. If I programmatically change the influence radius and rebuild everything/lightning, the sphere reflection visual presentation in editor does update once it is finished. I still support the native support as it updates immediately.

    Originally posted by G.Lecter View Post
    BTW, I came across another thing that needs to be scaled if the plugin doesn't do it already: CullDistances.
    It doesn't (in case you mean "Cull Distances" in a CullDistanceVolume actor). Thanks for that. I could have find it when I would be about testing several other common Actor types. Haven't got the time to do so.

    Leave a comment:


  • replied
    Originally posted by RattleSN4K3 View Post
    I am working on this. And now I'm questioning whether the radii (and other props) have to be updated for the ReflectionCapture actors/comps. The visible represenation of the capture is related to the Actor Scale and is in/decreased. Not sure if this really results into updated data, from my tests it doesn't. Sadly, I have to add native support again as there's no way to update the reflection capture's reflection from Blueprint (the process which is done if you change a value of the actor's properties in the details tab, it will update the data automatically).
    Reflections are automatically updated when you build lighting too. You might not need any specific code for that.

    I'm currently implementing/testing/investigating scaling Sound actors (AmbientSound). These are really tricky. The relevant scaling requiring properties are stored in the attenuation settings. But these settings can either be in the SoundCue (in case of using a SoundCue as source), the Sound class, the overridden sound class or the AmbientSound actor itself if it overrides these settings. Only in case of such overriding props, I am able to change these dynamically as all the other things are per-asset and not per-level/placed actor. Checking for this case isn't problematic, but how to expose this to the user? I mean I could extract the attenuation settings from the soundcue/soundclass, apply this to the placed actor and scale this (and on revert remove it)... but is this really the desired behavior... hmmm.
    That sounds like the best approach to me. You have to advise somewhere that you would no longer be able to change the soundcues to make global changes to the map once scaled, but I think that's OK. You really don't want to edit values in the soundcues themselves as those might be stock assets and/or they may be used in several maps at once.

    ---
    So, won't a plugin version be ready for MapCore? My level is pretty much finished at this point and I'm going to scale it down on Sunday or so... Like I said before, I can live without the plugin but I would really appreciate having it if possible...

    BTW, I came across another thing that needs to be scaled if the plugin doesn't do it already: CullDistances.

    Leave a comment:


  • replied
    Originally posted by G.Lecter View Post
    - ReflectionCaptures aren't getting their radiuses changed.
    I am working on this. And now I'm questioning whether the radii (and other props) have to be updated for the ReflectionCapture actors/comps. The visible represenation of the capture is related to the Actor Scale and is in/decreased. Not sure if this really results into updated data, from my tests it doesn't. Sadly, I have to add native support again as there's no way to update the reflection capture's reflection from Blueprint (the process which is done if you change a value of the actor's properties in the details tab, it will update the data automatically).
    Last edited by RattleSN4K3; 06-23-2016, 09:29 PM. Reason: Typo

    Leave a comment:


  • replied
    I'm currently implementing/testing/investigating scaling Sound actors (AmbientSound). These are really tricky. The relevant scaling requiring properties are stored in the attenuation settings. But these settings can either be in the SoundCue (in case of using a SoundCue as source), the Sound class, the overridden sound class or the AmbientSound actor itself if it overrides these settings. Only in case of such overriding props, I am able to change these dynamically as all the other things are per-asset and not per-level/placed actor. Checking for this case isn't problematic, but how to expose this to the user? I mean I could extract the attenuation settings from the soundcue/soundclass, apply this to the placed actor and scale this (and on revert remove it)... but is this really the desired behavior... hmmm.

    Another thing which I'm also not able to provide/do, changing the attenuation values from dynamic Blueprint actors / Level Blueprints. This would have been possible in UnrealScript back in UE3 but Blueprint doesn't have any access to these things in UE4 (such as nodes from the Blueprint editor class).




    Originally posted by G.Lecter View Post
    Something that could be awesome is a 'Grid & Snap' scaler, so you can work with smaller grids and keep everything aligned once you have scaled down your level. It doesn't sound like an easy thing to create though, [...]
    This is actually existing from 1.0 but noone knows how to do it . But with 1.4, I made this a bit easier to manage (Transform details re-shown). The MapScaler actor is used as root/pivot for every scaling process. This has the simple reason of keeping the map where your camera is located. Knowing that, if you place the actor at a proper place and scale the map with a working scale (depends on the grid you have), the grid will be intact after the map is scaled. You can try it by moving the scaler in the example map exactly on the grid/texture intersection and scale your map.

    1.0 | 2.0 | 0.5
    Click image for larger version

Name:	MapScalerGridScaling_1.0.jpg
Views:	1
Size:	122.0 KB
ID:	345748 Click image for larger version

Name:	MapScalerGridScaling_2.0.jpg
Views:	1
Size:	120.4 KB
ID:	345749 Click image for larger version

Name:	MapScalerGridScaling_0.5.jpg
Views:	1
Size:	141.5 KB
ID:	345750

    As long as the scaling value works with the grid size/snapping value, it works after the scaling process.

    If you use a improper scaling value, you can try changing the editor settings grid settings to fit grid size and snap size with a factor of your scaling level.
    Editor Preferences > ViewPorts > Section 'Grid Snapping'
    (but this is really buggy)

    Originally posted by G.Lecter View Post
    [...]and the fact that we have to wait for plugins to be recooked every time a new build comes out makes the traditional 'scale your level at the end' method more appealing to me, anyway...
    As long as the base engine doesn't change, the created plugin can be manipulated with a tool (I wrote). This wouldn't required the plugin to be recompiled. I've planned that from the very beginning as I know I'm not able to provide the plugin binaries at time. Yep, scaling should be applied at the end, this is the best way. Otherwise, you can use the MapScaler for play testing (PIE).

    Originally posted by G.Lecter View Post
    I have a couple of bug reports for you:
    - The MapScaler is not working properly with actors attached to other actors: when you scale a 'parent' actor, all its 'child' actors get scaled and change their positions accordingly. The MapScaler is scaling both the parent and the child actors, so the child actors end up being scaled twice and their sizes and positions are off.
    - ReflectionCaptures aren't getting their radiuses changed.
    Thanks for reporting. Seems like attached actors are already re-scaled if parent changes scale. Thought it wouldn't therefore I haven't checked it .

    ReflectionCaptures are likely not the only actors/volumes . Thanks for reporting it, gonna check if there are more things like that. In this case, I can change the radius with Blueprint nodes (except updating the render component, which might not be required).

    Originally posted by G.Lecter View Post
    My level has reached the 5000 actors milestone already and hadn't had any crash so far, so good job on that optimization!
    There are 2 features which will be disabled at that stage - "Update Undo for New Actors" and "Update Undo for Changes". It's likely you don't even need/use these.
    Last edited by RattleSN4K3; 06-03-2016, 10:04 PM. Reason: Typos

    Leave a comment:


  • replied
    Something that could be awesome is a 'Grid & Snap' scaler, so you can work with smaller grids and keep everything aligned once you have scaled down your level. It doesn't sound like an easy thing to create though, and the fact that we have to wait for plugins to be recooked every time a new build comes out makes the traditional 'scale your level at the end' method more appealing to me, anyway...

    I have a couple of bug reports for you:
    - The MapScaler is not working properly with actors attached to other actors: when you scale a 'parent' actor, all its 'child' actors get scaled and change their positions accordingly. The MapScaler is scaling both the parent and the child actors, so the child actors end up being scaled twice and their sizes and positions are off.
    - ReflectionCaptures aren't getting their radiuses changed.

    My level has reached the 5000 actors milestone already and hadn't had any crash so far, so good job on that optimization!

    Leave a comment:


  • replied
    Originally posted by G.Lecter View Post
    Can't think of any other actor apart from Blueprint stuff perhaps: I haven't tried this myself yet but, if I created a BP-Class with a light in it, would the MapScaler change the light radius in all the Blueprint actor instances in the map? Would that work without the plugin?
    It would work if implemented. It isn't . I would be able to do this in Blueprint but it adds an overhead to the process which then might abort it (due to the Iteration limitation per Tick). Gonna see how it turns out to work. The last time I optimized the scaler was with DM-Chill where I also noticed of having to scale fog actors accordingly. Without that optimization process, maps like DM-Chill or DM-Outpost23 (with like 5000+ Actors) maybe abort the process (=Blueprint VM crashes/exits) due to many operations per execution. I've tried to minimize the process to the very minimum but I can't ensure the MapScaler will work for every map with such a big actor count. I've noted that in the Readme. The MapScaler will also disable some costly features if the map is reaching such high count value.

    I will see how Sequencer works. Probably these have to be scaled as well (respectively the data). Hopefully it works with Blueprint, otherwise I have to use C++. And that doesn't even guarantee that's I'll be able to edit these things on the fly from external source. These days the engine/framework restricts a lot (even where it doesn't make sense; private vs. protected for instance).

    I also need to review the matinee scaling. Gonna check what things are done in a normal workflow. If i'm correct, Tuba/Underland should still have a matinee scene for the camera fly in the tutorial (not sure if this still exists).

    Other than that, I hopefully covered all of the cases a mapper would need to have it re-scaled (respectively ignored or re-aligned). I haven't got that much of feedback/reports (compared to how much this tool is used) therefore I am thinking it is enough / working. Sounds is one things which I haven't thought of and will add to the next version (hopefully without any requirement of the C++ backend).


    PS: I've also tried a runtime scaling mutator. Sadly it didn't work as BSP data has to be updated. I am still investigating how to approach/solve this feature. It is intended as testing tool. So users would be able to load any map and play it in any scale they like (offline/locally/singleplayer). This could help testers checking what scale a map fits the best and don't have to rely on the author to do a re-cook/build for every scale. I can also think of some authors wouldn't want this (as this can lead to false feedback), so I would support that by having a method to disable runtime scaling. All of this is the next big step which I think is not gonna happen any time soon. Let's see.
    Last edited by RattleSN4K3; 06-01-2016, 07:22 PM.

    Leave a comment:

Working...
X