Fr0stbyte's Development Log

If we have already talked about this situation let me know with a "yes"


Say i have a ship out in space and im just watching the minecraft planet. A player on the planet creates his ship and decided to take it to space. He takes it to space while i watch him do so. What will that be like? What is my view of him leaving the planet toward me? Will he automatically appear in space in front of the planet? Or will he appear as speck that grows larger as he gets closer to me?

again...If we have already talked about this situation let me know with a "yes" and ill look for the thread or post.


please only devs answer.

Can't guarantee you will see the ship all the way out to a single pixel size, though it's not impossible. You will be able to see it awfully far off, though, and depending on the size of the planet, how close you are to it, and how good your PC is, seeing the ship take off from the surface should be possible.

fr0stbyte124 wrote:

Can't guarantee you will see the ship all the way out to a single pixel size, though it's not impossible. You will be able to see it awfully far off, though, and depending on the size of the planet, how close you are to it, and how good your PC is, seeing the ship take off from the surface should be possible.

So what this means is tactical scouting of planets will acutely be useful?

Most things are going to be done via sensors at ranges where you can't actually see your target, so hard to say. People with better PCs already get a better playing experience. Don't want to add tactical advantage to the list.

Definitely not. I don't want players being blown out of the sky because their computer couldn't handle the oncoming barrage of fire long enough for them to raise shields.

So, any progress?

Some, though the last few weeks have been a logistical mess with the moving and the new job.

I'm working on a new file format for long distant terrain which only contains what is necessary for rendering and can be done with very little parsing. Aside from that I'm building a test platform in java which will let me load and experiment with bare bones terrain code separately from Minecraft. This in turn will make it easier to profile and debug and should help a lot in the long run.

The idea with the file system is to make a dense map of block occupancies in the chunk with 1 bit per block. Only surface exposed blocks are counted in the map. After the map, all corresponding block IDs and metadata are stored linearly with empty spaces removed, using the bit map to figure out where each goes. The next section is texture information and will be stored in the same format as their corresponding pages in video memory, which I don't think I've discussed yet. This face information is stored as a hierarchy of visible structures along with meta data describing the shape of the structure, with the surface being the topmost element. Structures are loaded from disk or caches on an as-needed basis depending on their visibility potential. For instance, disconnected pockets of caves have very low visibility potential while cave structures leading to the surface have higher potential. All of this is precalculated at some point after the current terrain generation stage.

This format makes the assumption that chunks not near any player will generally be non-interactive, so it is a waste to transmit everything constantly on the off-chance that it will be usable later on. I believe Robinton is attempting something similar but I do not know the specifics.

Couldn't you apply this to every chunk that a player is not in? Fully rendering only a chunk with a player in it would be pretty fast correct? Are there any downsides to that?

Ticks won't work properly in these regions because it's not actually loaded in chunk memory, nor does it contain enough data to do so. Perhaps this can be relaxed on multiplayer, but I can't guarantee it would work as expected.

fr0stbyte124 wrote:

Some, though the last few weeks have been a logistical mess with the moving and the new job.

I'm working on a new file format for long distant terrain which only contains what is necessary for rendering and can be done with very little parsing. Aside from that I'm building a test platform in java which will let me load and experiment with bare bones terrain code separately from Minecraft. This in turn will make it easier to profile and debug and should help a lot in the long run.

The idea with the file system is to make a dense map of block occupancies in the chunk with 1 bit per block. Only surface exposed blocks are counted in the map. After the map, all corresponding block IDs and metadata are stored linearly with empty spaces removed, using the bit map to figure out where each goes. The next section is texture information and will be stored in the same format as their corresponding pages in video memory, which I don't think I've discussed yet. This face information is stored as a hierarchy of visible structures along with meta data describing the shape of the structure, with the surface being the topmost element. Structures are loaded from disk or caches on an as-needed basis depending on their visibility potential. For instance, disconnected pockets of caves have very low visibility potential while cave structures leading to the surface have higher potential. All of this is precalculated at some point after the current terrain generation stage.

This format makes the assumption that chunks not near any player will generally be non-interactive, so it is a waste to transmit everything constantly on the off-chance that it will be usable later on. I believe Robinton is attempting something similar but I do not know the specifics.

So essentially this the fancy way of saying "it's like a painted backdrop"?

Lord Mackeroth wrote:

fr0stbyte124 wrote:

Some, though the last few weeks have been a logistical mess with the moving and the new job.

I'm working on a new file format for long distant terrain which only contains what is necessary for rendering and can be done with very little parsing. Aside from that I'm building a test platform in java which will let me load and experiment with bare bones terrain code separately from Minecraft. This in turn will make it easier to profile and debug and should help a lot in the long run.

The idea with the file system is to make a dense map of block occupancies in the chunk with 1 bit per block. Only surface exposed blocks are counted in the map. After the map, all corresponding block IDs and metadata are stored linearly with empty spaces removed, using the bit map to figure out where each goes. The next section is texture information and will be stored in the same format as their corresponding pages in video memory, which I don't think I've discussed yet. This face information is stored as a hierarchy of visible structures along with meta data describing the shape of the structure, with the surface being the topmost element. Structures are loaded from disk or caches on an as-needed basis depending on their visibility potential. For instance, disconnected pockets of caves have very low visibility potential while cave structures leading to the surface have higher potential. All of this is precalculated at some point after the current terrain generation stage.

This format makes the assumption that chunks not near any player will generally be non-interactive, so it is a waste to transmit everything constantly on the off-chance that it will be usable later on. I believe Robinton is attempting something similar but I do not know the specifics.

So essentially this the fancy way of saying "it's like a painted backdrop"?

Closer to a 3d skybox.

fr0stbyte124 wrote:

Ticks won't work properly in these regions because it's not actually loaded in chunk memory, nor does it contain enough data to do so. Perhaps this can be relaxed on multiplayer, but I can't guarantee it would work as expected.

Interesting. I wonder if this is a way to make a super-fast server to run on weaker server builds. It would make an epic creative server, except for the fact that redstone might bug out a little...

I love it when dev logs get updated.

Buggy1997123 wrote:

Lord Mackeroth wrote:

fr0stbyte124 wrote:

Some, though the last few weeks have been a logistical mess with the moving and the new job.

I'm working on a new file format for long distant terrain which only contains what is necessary for rendering and can be done with very little parsing. Aside from that I'm building a test platform in java which will let me load and experiment with bare bones terrain code separately from Minecraft. This in turn will make it easier to profile and debug and should help a lot in the long run.

The idea with the file system is to make a dense map of block occupancies in the chunk with 1 bit per block. Only surface exposed blocks are counted in the map. After the map, all corresponding block IDs and metadata are stored linearly with empty spaces removed, using the bit map to figure out where each goes. The next section is texture information and will be stored in the same format as their corresponding pages in video memory, which I don't think I've discussed yet. This face information is stored as a hierarchy of visible structures along with meta data describing the shape of the structure, with the surface being the topmost element. Structures are loaded from disk or caches on an as-needed basis depending on their visibility potential. For instance, disconnected pockets of caves have very low visibility potential while cave structures leading to the surface have higher potential. All of this is precalculated at some point after the current terrain generation stage.

This format makes the assumption that chunks not near any player will generally be non-interactive, so it is a waste to transmit everything constantly on the off-chance that it will be usable later on. I believe Robinton is attempting something similar but I do not know the specifics.

So essentially this the fancy way of saying "it's like a painted backdrop"?

Closer to a 3d skybox.

I'm not sure that's the right analogy. Essentially it's a compressed version of the render data rather than block data.

Still have no idea what your talking about Fr0st.


Edit: keep it around 4 letter words, maybe 5.

hyperlite wrote:

Still have no idea what you're talking about Fr0st.


Edit: keep it around 4 letter words, maybe 5.

Can I use the word 'homophones'?

mansounds...?

Words that sound the same, but are spelled differently, I think. To and too are some

ah ok



thank you haxorx owl man!

I just had a crazy idea for another way ships could be handled: a forth dimension of space.

I got the idea 5 minutes ago while I was watching the mcf load, and I saw the background was a single image with several small overlays.

So, just like you need to add a third dimension(Z) to control the position of images relative to eachother, we add a forth(E?) to control the position of the 3-dimensional worlds relative to each other. From the little I know of higher-dimensional physics, this ought to work. Maybe.

Buggy1997123 wrote:

I just had a crazy idea for another way ships could be handled: a forth dimension of space.

I got the idea 5 minutes ago while I was watching the mcf load, and I saw the background was a single image with several small overlays.

So, just like you need to add a third dimension(Z) to control the position of images relative to eachother, we add a forth(E?) to control the position of the 3-dimensional worlds relative to each other. From the little I know of higher-dimensional physics, this ought to work. Maybe.

That's close to how quaternion math works, only that resides on the surface of a hypersphere, which is how it reduces the dimensionality again.

I'll keep it in mind, but I'm guessing Euclidean math will be sufficient for our purposes, at least for entities.

fr0stbyte124 wrote:

Buggy1997123 wrote:

I just had a crazy idea for another way ships could be handled: a forth dimension of space.

I got the idea 5 minutes ago while I was watching the mcf load, and I saw the background was a single image with several small overlays.

So, just like you need to add a third dimension(Z) to control the position of images relative to eachother, we add a forth(E?) to control the position of the 3-dimensional worlds relative to each other. From the little I know of higher-dimensional physics, this ought to work. Maybe.

That's close to how quaternion math works, only that resides on the surface of a hypersphere, which is how it reduces the dimensionality again.

I'll keep it in mind, but I'm guessing Euclidean math will be sufficient for our purposes, at least for entities.

Forgive me my ignorance, oh great master!

fr0stbyte124 wrote:

Buggy1997123 wrote:

I just had a crazy idea for another way ships could be handled: a forth dimension of space.

I got the idea 5 minutes ago while I was watching the mcf load, and I saw the background was a single image with several small overlays.

So, just like you need to add a third dimension(Z) to control the position of images relative to eachother, we add a forth(E?) to control the position of the 3-dimensional worlds relative to each other. From the little I know of higher-dimensional physics, this ought to work. Maybe.

That's close to how quaternion math works, only that resides on the surface of a hypersphere, which is how it reduces the dimensionality again.

I'll keep it in mind, but I'm guessing Euclidean math will be sufficient for our purposes, at least for entities.

Yeah, I kinda figured that Euclidean math would be more than enough, but if you think about it there will be a sort of fourth dimension(ignoring quaternion rotation): world depth. If there is nesting, then the world depth is how deeply it is nested, but I think this is more a imaginary number than anything.

Anyway, cool.

Keep up the good work. BAAAA

Frostbyte, notice ^his^ sig? Do you see the light spots on the outside of the hull? Is there a way to prevent light spots like those? Because it would probably look odd for a ship in pitch black space to have dark and light spots.