Int64 Vector "Set World Origin" Blueprint Node

Hello, i would like to request that the Blueprint node “Set World Origin” is changed to Int64 Vector instead of Int Vector, if possible. When making endless or even just very big open world games, often seen in open world space games, the Set World Origin node being an Int Vector is very limiting. Thank you!

Would this at all be possible? would be a huge help, thanks.

It can’t, the rest of the engine does not have 64-bit precision, that’s why it uses World Composition with origin shifting to make large worlds.

maybe focus on a world that people want to play instead of having a huge world thats boring to play just for the sake of having a huge world

@darthviper107 gotcha, thanks.

@Raildex_ seems like a weird comment to make when you don’t know anything about the game.

2 Likes

I can already imagine how it plays when you ask such question :stuck_out_tongue:

@Raildex_ Off topic, but look at games like Star Citizen, it promises a huge open world and people are very excited. Same with No man’s sky, Elite dangerous, etc. If you can populate these big open worlds with interesting stuff to do, it doesn’t have to be boring. And i like how you’re saying “just for the sake of having a huge open world” when you don’t know the game haha.

We’re making modular assets and using procedural generation to fill the world, take a look at NMS way of going about it, they did have a budget but it wasn’t really used on the programming and modeling, that was already planned out and doable with the lower budget they had initially. Even so our world is not nearly as big as any of those games, we have confined planet levels and a single solar system (our solar system) not 1:1 scale. If you go about it in a thought out way it’s totally doable! Also we already have the worlds in place, unreal engine 4 needs no modifications to get that to work, just some workarounds here and there - this issue is the only thing we have not been able to work around yet.

As already stated, the engine use floating point for every transform operation, not double.
You saying the engine needs no modifications for this is bizarre. If the only thing you do is change that node to double precision, when processing that vector the unmodified engine is going to convert the value back to floating point value, making the change to that node meaningless.

The reason we need this is to be able to save the location, world origin shifting works fine for us even in locations further than the floating point limit.

I’ve done research before on floating point precision and had issues in other engines with this. As Epic seems to be pushing bigger and larger worlds with its recent updates being for open worlds and massive terrains, I wouldn’t be surprised if at some point in the future we don’t get something like this under the hood. Epic’s crew are literally wizards. While I don’t personally **need **ityet, I think having the ability to handle these massive open galaxies would be awesome. I imagine it would be something they would do in tandem with origin shifting somehow. I bet @Fabriciuz is doing some kind of cool space game, and this is marked as a [Feature Request]. I bet there are others who would like this as well. I don’t have the links right off, but there are some really cool looking indie space games in the works that benefit from this sort of thing.

P.S. Some people might like flying around in large space games. Personally, I like that sort of game.

2 Likes