Ahhhh I see, doesn’t look like there’s much we can do about the engine internals on this one. Might be best to look into possible workarounds. With these sizes of procedural generation, are you generating planets? What’s your full use case? I might be able to find a better way.
im using it as a highway for a rhythm game editor. a bit complicated to explain, but essentially the highway is the song length * 1000 (or 10 for scale). Each mesh part is one section of bpm change. so this means if i only have a bpm change at the start of the song, then its going to be running all the way to the end of the song, which will be 99% of maps.
my use case with this highway isnt super simple as well, as i use it for stuff like note detection and grabbing notes of notes. for example, if i wanted to grab all the notes from the current bpm to the next one, i could use the highway piece and grab the overlap data rather than needing to slowly grab the data through an array.
something someone suggested to me was to use many small mesh pieces, but that complicates stuff for me quite a bit. I need to keep track and manage literally every actor/actor component that is spawned in my level, often times needing to index through them or sort them by different variables so id want to minimize object counts as much as possible.
seeing as there isnt really a work around for this, do you think this will be fixed soon? i can always roll back to unreal 4.26 in the mean time and then update my project when the time comes. the project size will be relatively small all things considered because its procedural in nature. its just super complex to logic out.
if you want to check out what im using as a reference, you can take a look here. i made this in unreal 4.26, but im making a new editor for a different game and ideally wanted to do it in unreal 5 to use lumen for my all the lighting that ill need to do. GitHub - CANA-Dan/ParEdit: A 3D Custom song editor for Paradiddle
That’s usually my answer as well, instead of spawning larger tracts, have them be “virtual” and only spawn in when they need to within a couple thousand units. Though your style of rhythm game isn’t nearly as simple as something I’ve modded like beatsaber. You may be looking to roll custom code entirely, which would be more tedious.
I don’t know a time scale for fixes like this, but a detailed report if possible can speed it up immensely.
ayo? youve modded peat saber? what mod? i play the ■■■■ out of beat saber.
Haha, unfortunately I can’t tie my work identity to my actual developer stuff due to rules so I can’t say much but it was just an early attempt at an auto-mapper. It had pretty decent problems once proper tools came out.
But on to the problem at hand, if you can simplify your data to be time based you may be able to just spawn them in at where they’d be once they are close enough. That’s all pretty dependent on how your rhythm game’s structured. Best case would be to “fake” the notes’ distance and keep the player/frets stationary for the sake of simplicity.
Is your design basically long frets like your mod?
in this case, i need to have all the highway parts available to the user. im working on the editor side of things first as i want the editor to be excellent, and at minimum i need all the highway sections in view at once, as well as any that are under selected notes. i use the highway to get bpm information and quickly detect what notes are where.
for now i think im going to move back over to unreal 4.26. i dont need any of the new feature of unreal 5 yet (nanite, lumen, or any of that stuff) as im working solely on backend rn, but i will be wanting to add it probably in about 6-8 months, which is enough time that a fix could have come out.
1 Like
im now on unreal engine 5.2 and this issue still persists. not totally sure what to do. i guess i could submit another report, but my last one didnt show up on the report website. not sure if that was because it glitched out and never got added, it was never reviewed (im assuming reports get reviewed), or it was reviewed but they decided not to add it.
Sorry about that, I think your report got wrapped into the previous issue as a duplicate, the one you mentioned previously was recently updated with a target fix of 5.3. I’m certain the extra reports helped out. I’d put in a PR for it myself if I could pinpoint where the issue is, as if it’s just somewhere the 64 bit float is getting shifted down it would be a relative straight forward patch assuming that doesn’t break some core functionality (though because it is pushed to 5.3 it’s likely tied to more than just that function).
well, i guess time to wait then. yeah i sure hope this is resolved with 5.3. would be very cool if it was.
Hopefully it will be! Alternatively if we can keep an eye on PRs we may be able to integrate whatever fix they come up with directly before the update occurs.
ah thats true. i should probably clone the engine at some point. that way i can mess around with the latest stuff. its just so large lol.
It’s actually recommended that once you settle on a version for your project to work from source (for versions that are done with their fixes) to build the source and use that, in case you need to edit the source, or a fix comes around, or even if you need to revert a change but want to keep the current versions features. For on of my projects I use a slightly tweaked 5.1 install and it will likely remain that way for that project’s foreseeable future.
i see. thats a good idea. ill probably do that.
1 Like
to mark this as answered, the engine has updated to 5.3, and with it these floating point errors errors are no longer and issue; the accuracy is the same as pre 5.0, which is 32bit like it should be.
Local space is accurate as well, so actor components are correct too (like instanced static mesh). overall quite please. now i can actually start work on my game.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.