Announcement

Collapse
No announcement yet.

Int64 Vector "Set World Origin" Blueprint Node

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

    [FEATURE REQUEST] 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!

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

    Comment


      #3
      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.

      Comment


        #4
        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

        Comment


          #5
          darthviper107 gotcha, thanks.

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

          Comment


            #6
            I can already imagine how it plays when you ask such question

            Comment


              #7
              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.

              Comment


                #8
                How many hundreds of millions of dollars do you have to make such a huge game like that?
                You can pay programmers to implement that for you, just like Star Citizen did. Just just changed the entirety of CryEngine for that and created a custom engine in the end to make it work...

                That is going to cost nothing compared to the amount of 3D assets you gonna have to buy to fill that huge world.
                | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

                Comment


                  #9
                  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.
                  Last edited by Fabriciuz; 08-05-2019, 12:46 PM.

                  Comment


                    #10
                    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.
                    | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

                    Comment


                      #11
                      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.

                      Comment

                      Working...
                      X