Jump to content

Mathig

Alpha Tester
  • Posts

    6
  • Joined

  • Last visited

Posts posted by Mathig

  1. I'm not sure if i understand your question.

     

    But if you're wandering about the size of the voxel grid itself i think NQ answers that here.  

     

    https://board.dualthegame.com/index.php?/topic/14-voxel-tools-pre-alpha-game-design/#entry131

     

    This is exactly what I was looking for, thanks.

     

    So, just to be clear, the only thing that worries me is whether or not the terrain shown at the beginning and end of this video is actually voxel based or something else.

     

    Now, I agree that the terrain shown in the middle absolutely is Voxel-based. However, I'm not convinced the two are the same. I'm also a little confused why the higher mesh detail isn't centered around the camera for that part of the video, but I imagine it would be almost as hard to program a fake mesh enhancement that convincing as a real one, so...

     

    @Wesbruce your example is poor, because it is very obviously voxel based. Note the texture is almost the same flat tone for everything. It's not displayed as cubes, but the data is obviously stored as cubes.

     

    What keeps tripping me up is those small indents on the ground and the lack of obvious tiling which you should see unless they are messing with the textures. Also, why the tower at 10 seconds is floating on the right.

     

    However, after staring at the terrain I can kinda sorta see tiling textures that are maybe randomly rotated or cropped (off of a larger single texture), perhaps based on a seed derived from it's coordinates? Perhaps small variations in height are actually non-existent and are really just baked on as part of the texture?

     

    Yeah, now I'm starting to see it. I guess I didn't understand that dual contouring was basically averaging terrain meshes over local space. I thought it was storing shapes as meta data. That explains a lot of why the spherical tool doesn't seem to "work" as intended, or behaves rather unpredictably.

     

    I have a very hard time believing that those voxels are 100 cm though. They look much more like 25 cm. Anyway, that doesn't matter either way.

     

    Thanks @Wesbruce for the pdf. While I probably didn't read it closely enough to fully understand it, it did help.

  2. Mathig your out of date with how voxels work now. You can generate that terrain mesh quite easily in a voxel engine. That's just a voxel terrain, relatively smooth, with decorations; the rocks. I can't see why you think it's a non voxel terrain.

     

    As far as I know, voxel technology means saving meta-data to a grid of a certain mesh. In Minecraft that meta data is a block type which indicates which block it is, grass, dirt, what-have you. On top of the meta-data mesh, you need to generate a surface to attach textures to. Minecraft does this by generating planar faces in between the block and any transparent blocks. Dual Contouring, to my understanding, generates a surface based purely on that mesh.

     

    In their video here at 1:47, that is clearly voxel based. At 1 second, however, I'd argue the terrain isn't. I'll just assume the rocks are effectively elements and were custom designed. The terrain, especially towards the bottom right, however, does not look like it is flat except for the occasional 20cm change over a distance of 20cm. The terrain towards the middle-left isn't what I'm worried about, since I can't see it clearly. It's the bottom right that concerns me.

  3. Do you mean this? If so, then no, it does not answer my questions regarding voxel mesh size. If anything, those videos in specific imply something quite dishonest going on behalf of Novaquark, but as I've said, I thought to give them the benefit of the doubt.

     

    Specifically, this video seems to be an unmistakable example of non-voxel based terrain masqueraded as voxel based terrain generation. Would you like me to explain why that terrain isn't voxel based, why non-voxel based terrain is a terrible design decision(for Dual Universe), or what dark scheme I think Novaquark could be up to? It's obvious that either I'm missing some major feature of development, or NovaQuark isn't being honest with development, and that concerns me.

  4. So, I wrote this long comment, but it didn't bode well for Novaquark. So, I'm giving them the benefit of the doubt. What is the lowest mesh size for the voxel terrain. (If you aren't a dev, please link some form of source) I'm also curious why the smallest mesh size ever used is on the order of 100 mm, but the terrain looks to be on the order of 1 mm or even smaller.

  5. Scripts run locally on your PC, which requires you to be present near the DPU blocks. You can assign operators in your organisation to run the automated factories in your stead, while you run around space, meeting new people and prying open their hulls with superior firepower.

     

     

    The locally-run aspect, also reduces the framerate issue on other players, just because a person may elect to make the equivalent of a Drone Swarm for their private drone fleet. So, DUAL, does it the way Space Engineers should have done it :P

    Firstly, do you have any confirmation whether or not scripts will run locally on the users PC? This is a massively important feature, as it determines whether or not the game could be feasible to begin with. I have put thought into a number of systems, any one of which, would brutally murder a server.

     

    One is an accidentally bugged code which features an infinite loop that runs a bunch of intensive commands. If these ran on a server, you could on-demand crash local nodes.

     

    Another is an cleverly constructed code designed to replicate itself. That is, teach a robot to mine resources, develop them into another robot, and copy it's data morphed for cooperative play for that other robot. In other words, a literal hive mind that, once started, will reproduce exponentially.

     

    While you're building your hive mind, you could incorporate machine learning to spontaneously adapt and develop new code automatically to improve the hive-mind's function. Granted no one has done this in real life yet, but it is still possible someone could reach the singularity in-game and no one can know what will happen next. (Although perhaps the developers of Dual Universe would be more than happy to facilitate that development)

     

    IFF code ran on local computers, this sort of game play would merely crash the users PC, and not the server as a whole.

     

    Of course, there are also a number of things that can be done to limit the above from ever becoming an issue at all. For example, if you made it local to a certain distance ®, you'd prevent players from using more than r^3 DPU's which could potentially have their own limits on computational power. If you made it local to the player with some upper threshold of active DPU's or DPU operations per second, then you could prevent players from expanding too much by slowing down their operations (like EvE's time dilation).

     

    There are also a number of things that could be done that would eliminate various methods of play (in my opinion, less desirable), for example preventing AI from creating or activating other AI.

     

    Of course, if you let players crash their own PC, now you've opened the door to effectively installing a virus via your game, by allowing players to sell code that potentially damages the buyers PC. Which might now have legal ramifications for the developers, since it might be unreasonable to expect a reasonable video-game to burn out your recommended spec meeting hardware.

     

    I'm still quite the skeptic, though, so it'd be really nice if the devs have already thought of this stuff before I have.

×
×
  • Create New...