Fr0stbyte's Development Log

This is a topic archiving my development updates. This covers not only my development in FutureCraft, but also Project Copernicus, which for the time being are one and the same.

Anyone is free to post here, including non-devs. Questions are welcomed, but let's keep it over the outlined material.

===================
Thursday, October 13, 2011
===================

Right now I'm working on the new collision system. Originally I thought my changes could go in on top of the existing engine, but after playing with entity-ship interaction I've discovered that the current bounding box collisions have literally zero tolerance for error. If two boxes are overlapping even 0.000000001, then you will end up walking right through the wall like it's not there. And by introducing floating point multiplication, error is unavoidable. I got around it in my testing by adding tolerance levels to everything, but it's ugly, limited, and only a temporary fix. The whole engine needs to be overhauled and replaced with a more conventional one.

I'm trying to keep the changes localized to the Entity class, but I can't guarantee it will stay that way. It's also worth mentioning that this makes Copernicus incompatible with Robinton's Cubic Chunk mod (which isn't terribly surprising, as Robinton had to modify pretty much every class file that had anything to do with chunk access). I'll try to patch it later on (Mackeroth, did Robinton give you his source code or just permission to integrate his mod?) In any case, it's still too early in Copernicus development to even attempt that sort of thing. On the plus side, Copernicus will be able to make structures exist above the sky limit in the meantime (though cubic chunks would probably be better in the long run).

-------------------------------------
New Collision System Details.
-------------------------------------

The new collision system is an integral element of the Copernicus framework, and due to the complexity of everything that will rely on it, the math at this step has to be absolutely perfect, i.e. no guesswork. When you're doing stuff with a visual feedback there is a tendency to fiddle with signs and order of operations until you get the effect you want, but what you get could easily be the result of multiple mistakes canceling each other out. Those mistakes may in turn can create much, much larger and costlier complications later on. That happened once when I was working on a robot with a complicated chain of transformations and projections. I had to rewrite the model from scratch again just to fix it. I don't intend to make that mistake again.

As a result, development is going kind of slow, and I don't have anything flashy to show off, but I'm hoping it will pay off in the long run.

One of the major changes I'm working on is changing the orientation model (for Copernicus objects, not vanilla entities) from Euler angles to quaternions. With Euler angles, you have pitch, rotation, and yaw, and you apply each of them sequentially to a transformation matrix, but as you do that the frame of reference also shifts, meaning if you are an airplane and you pitch down and then yaw, you won't be yawing about the original y-axis, but instead the plane's local Y. It becomes non-intuitive and more importantly, nontrivial, to determine what rotations create a specific orientation (the problem is called "Gimbal Lock" and I would post the relevant wiki links but forum won't let me).

Quaternions, on the other hand, are a 4-Dimensional vector system which can describe rotations and orientation without the need for Euler Angles. Essentially a quaternion is a combined 3 dimensional vector and a scalar which together describe a single rotation about an arbitrary axis. I'll describe it in greater detail in a later post. The main thing with this is that it doesn't suffer from gimbal lock, and works rather well with vector math, which makes it ideal for Separating Axis Theorem (SAT), the collision model I will be implementing (I'll explain that in a later post, too).

The first thing to use the oriented bounding box will be the ship itself. This will define the airspace around the ship, determining whether an entity is onboard or nearby, so as to move the player along with the ship even if he is flying. I tried it with an axis-aligned box but it was far too rough at extreme angles, especially for really long ships.

The collision engine will contain optimized functions for every conceivable combination of collisions. Axis-aligned boxes, oriented boxes, spherical collision (where only proximity is important), maybe custom polygons (though not until there is a need for it).

Ship vs. world and ship vs. ship will contain additional optimizations which take advantage of the fact that:
1) All blocks in a moving chunk are aligned to the same axes and are evenly spaced and sized.
2) Non-cube blocks with collision can be estimated as cubic blocks on this scale without looking weird.
3) The future positions of the ship can be predicted.
4) Most of the factors in SAT are dependent on orientation and not position.

I'll go into deeper detail about the algorithm when I'm to that point. For now, I'm focusing on oriented boxes around the ship and letting the ship clip through terrain and other ships.

-----------------------------------
Ship Renderer Obstacles
-----------------------------------

Ship rendering isn't going as well as I had hoped. Right now I am copying the the index of the compiled render list for each relevant render chunk. To use it, you just translate the graphing coordinates to where you want your ship and execute that list. But there are two problems showing up with this method:

The first is that chunks of the ship occasionally disappear. I suspect the cause of it is that render indexes are reused and its contents overwritten with other chunks. Normally the chunks are far enough apart that you never see it. The chunk reappears is corrected when the real ship comes back into view. To avoid this in the future, once ships start being stored in the pocket dimension, we'll have to assign a unique set of render indexes for each ship so as not to conflict with the real world.

The second problem is the annoyance of getting the right coordinates for each render chunk. For reasons I am still unclear about, render coordinates are cut off at 0x3FF, or 1023, and then wrap back to 0. Negative coordinates start at 1023 and go backwards. It's non-intuitive and causes no end of trouble for determining the correct positions of every chunk. When the pocket dimension is implemented, I'm thinking about cloning the worldRenderer class, but pre-translating each ship chunk to ship-centric coordinates. It shouldn't overwrite any base classes and should give us more control over how ships are handled.

The other thing I was considering was rather than making the pocket dimension a Euclidean sort of warehouse for every flying object, instead encase each ship in a subspace of chunks which are locally connected, but not connected to any other ship. This would allow you to manipulate the size of the ship without running into other ships in the area. If each space has its own World identifier, local blocks should behave normally. It will take extra work but I think it will be handy in the long run.

........................................................
Copernicus Roadmap: Oct 13, 2011
........................................................

1: Render
2: New Collision Engine
3: Pocket World
4: Render Revisited
5: Object Interaction (redstone, construction, etc.)
6: Ship vs. World, Ship vs. Ship Collision
7: Isolated Pocket Spaces
8: Dynamic Lighting
9: Space...stuff
(SMP goes in there somewhere. It's priority will depend on how the other FutureCraft elements are coming along.)
------------------------
Future Plans(no order, no timeline):

Assorted Ship Features
Seamless World Portals
Better Explosion Physics
Latency-Hiding Techniques
Scalable LOD
Custom Camera Controls
In-World Assembly of Complex Objects
Scripting (of some sort)
Netcode Improvements
*classified*
*classified*

Wow. Just wow.

I literally didn't understand a word of that, and for once, it's not because you can't write (saying others do, not you). I think that just by reading that, my IQ jumped about 10 points. All this is coming from a person who has a nickname of "Captin Arrogance", and worse, lives up to it.
Perhaps I should ignore my study and finish reading that book on String Theory, so I have something to counter your blinding genius.

To answer you question: I got permission from someone important to use Cubic Chunks, but I never got the source code. I should probably go ask...
You said that some of the parts of Copernicus would make it incompatible to the Cubic Chunks mod. If you have the base code, could you make it work? (I have noticed that a lot of Copernicus relies on the chunk format of vanilla Minecraft).

I will mention this post to you on the Minecraft Forums.

(I'm hoping the explanations will make more sense once I can offer up concrete demonstrations and visual aids. But apparently I can't post external links for the first week, so that will just have to wait.)

Here's the list of classes cubic chunks overwrites:

ChunkProviderClient
BlockShapedCharge
WorldGenDeepCavern
ChunkProviderSky
ChunkProviderLoadOrGenerate
IChunkLoader
RenderGlobal
ChunkProviderHell
GameSettings
client/Minecraft
BlockChest
BlockSand
ChunkCache
McRegionChunkLoader
EmptyChunk
EntityPlayer
NibbleArray
ChunkProvider
ChunkLoader
ChunkBlockMap
GuiIngame
IChunkProvider
RegionFileCache
ItemBlock
ChunkProviderGenerate
Chunk
MetadataChunkBlock
Entity
World
WorldGenDungeons
NBTBase
NBTTagCompound
ItemMap
BlockMushroom
BlockDoor
BlockPistonBase
SpawnerAnimals
MapGenCaves
MapGenBase

Right now, Copernicus just overwrites Entity and Chunk, and the latter is just a bugfix to give entities collision above the sky limit. After the pocket space is introduced, it could potentially touch quite a few more classes; I'm still trying to figure out exactly what. Since it doesn't have to work in vanilla space, we do get a bit of leeway on this though, so I think changes to the original could be kept minimal, but Entity is getting an aggressive rewrite. I can probably make a patch based on decompiled code, but the original source would be easier and more reliable.

And hey, when you get done reading up on String Theory, we can incorporate it into the mod! I was afraid we weren't going to be able to add artificial micro black holes as an energy source because I wasn't sure how to model it in 11 dimensional space. But you can do that now, so we're good

I tried to decompile the Cubic Chunks Mod, but for some reason, I couldn't. In assuming it's the same for you.
The concept of super-string fascinates me. One dimensional strings that vibrate through 11 dimension is, interesting. Still, it is only a hypothesis (or has it officially become a theory).

If you had the base code for the Cubic Chunks Mod, AT THIS STAGE wouldn't it be easy to include their code for "entity" with your version, and simply get rid of your "chunk" patch, as there is no longer need for ships to be above the height limit.
I do understand that in the future, it will become more difficult. If you were to start creating the rest of Copernicus from the files already modified by Cubic Chunks, than wouldn't it be completely compatible?

Additionally, would it be possible for you to post a download of Copernicus in Area 51? I'm interested in seeing how you made that mountain move. That ship was about the size of an assault ship, I think - or at the very least a dreadnought - and I'd like to fiddle with it a bit. I'm sure the whole team would like to, actually, depending on how many of us there are left.

Dr. Mackeroth wrote:

I tried to decompile the Cubic Chunks Mod, but for some reason, I couldn't. In assuming it's the same for you.
The concept of super-string fascinates me. One dimensional strings that vibrate through 11 dimension is, interesting. Still, it is only a hypothesis (or has it officially become a theory).

One of the primary criticisms of string theory is that were it real, it would still be impossible to prove with anything approaching our technology level.

Quote :

If you had the base code for the Cubic Chunks Mod, AT THIS STAGE wouldn't it be easy to include their code for "entity" with your version, and simply get rid of your "chunk" patch, as there is no longer need for ships to be above the height limit.
I do understand that in the future, it will become more difficult. If you were to start creating the rest of Copernicus from the files already modified by Cubic Chunks, than wouldn't it be completely compatible?

The chunk patch would be rendered moot by the Cubic Chunks mod, yes. I would rather port the rest in one sitting if I could.

Shiva wrote:

Additionally, would it be possible for you to post a download of Copernicus in Area 51? I'm interested in seeing how you made that mountain move. That ship was about the size of an assault ship, I think - or at the very least a dreadnought - and I'd like to fiddle with it a bit. I'm sure the whole team would like to, actually, depending on how many of us there are left.

If you have a single-player copy of Area 51 I could arrange something, but multiplayer is a whole different beast. You would have to add new protocol for defining the body of the craft along with it's motion, and fix some of the time dilation errors that currently accompanying craft like minecarts and boats, along with a few other things I know I am forgetting about. That's a full project in and of itself.

Right now, I have to specify the dimensions and orientation of the craft by hand in the code (a blob filter search is coming after the collision engine and before the pocket world stages) and there is a bug which prevents the ship from being visible if it starts in the -X or -Z quadrants (mentioned it briefly under "Ship Renderer Obstacles") but otherwise it works just fine as far as flying goes, so sure.

*edit*
Lol, I'm dumb. I thought Area 51 was the build server.
Okay, I'll clean up the code and see if I can't fix that one render bug and release what I've got there.

Nice, I love changelogs.

I don't see why 5, 8, and in world assembly of complex objects is a problem. Unless you mean number 5 as in interaction between craft and world objects(like redstone). 8 is- oh wait the craft-world lighting... The in world assembly of complex objects, do you mean building stuff on a ship, or something else?

Also, to hide help hide latency, I have a idea. How about the servers measure ping between the two of them every so often, and according to that pin they can delay applicable(ping vulnerable and exact-timing flexible) events according to the average recent ping.

And when cordinating events, they could send along a timestamp of when it happened according to that server's local clock, which the two servers sync every so often. When a event that excludes another event happens, the other event's effects are stopped or reversed(exc, someone punches and kills someone else who would do the same to the first person if he did not die, but due to latency the first person or both of them die.)

5 deals with the fancy stuff that Zeppelin is working on: flipping switches, breaking blocks, opening doors, and activating pistons.
8 is things like making entities get lit by the flying ship, prevent rain from falling inside the ship, and making ships cast shadows on the ground.

What you are describing falls under improvements to the network code, rather than latency hiding. And while they are good suggestions, they would be part of a different framework. Wait, we are doing multi-server stuff, aren't we. It might make an appearance after all...

But what I was referring to with latency hiding is doing things with lots of calculations, like crashing a ship into the ground and causing a crater, but distributed over the time before the event takes place. You could even be ready with animations and new chunk renders. Or it could consist of simple things like prioritizing the chunk updates of pistons and redstone so they act as expected even at a distance.


Next progress update will probably be Thursday.

fr0stbyte124 wrote:

5 deals with the fancy stuff that Zeppelin is working on: flipping switches, breaking blocks, opening doors, and activating pistons.
8 is things like making entities get lit by the flying ship, prevent rain from falling inside the ship, and making ships cast shadows on the ground.

What you are describing falls under improvements to the network code, rather than latency hiding. And while they are good suggestions, they would be part of a different framework. Wait, we are doing multi-server stuff, aren't we. It might make an appearance after all...

But what I was referring to with latency hiding is doing things with lots of calculations, like crashing a ship into the ground and causing a crater, but distributed over the time before the event takes place. You could even be ready with animations and new chunk renders. Or it could consist of simple things like prioritizing the chunk updates of pistons and redstone so they act as expected even at a distance.


Next progress update will probably be Thursday.

Oh, but I still don't see why number 5 would be a problem. Zepplins has that problem because a ship is made of entitys, but Copernicus ships are real and simply replicated visually in the desired location, so those would work automatically.

And your right, I forgot that when a player travels to another server they arn't still on the original but actually connected to the other server.

Man, this moderator thing is scary. I almost edited your post thinking it was the reply button. Gotta be more careful.

Anyway, I'm hoping it won't be a problem, but since it hasn't been done by Zeppelin, it's entirely new ground and invites unforeseen complications, like the zero-tolerance collisions did. To interact with objects you have to first make a custom raycaster like what Eloraam did for Red Power, and figure out how to make it work seamlessly with any number of interacting worlds, something I haven't even attempted yet. That's why it's got its own number.

Okay, I have a bit of time today, so the log is getting an update today, rather than tomorrow. As a result, the stuff I'm working on is still a WIP, though it's pretty close to completion.

========================
Wednesday, October 19th, 2011
========================

----------------
Orientation
----------------
I discussed this a little bit in my last update, but I don't think I did a very good job and lost some folks along the way. This time I'll have visual aids to help out.

An object that can turn and rotate in any direction is said to have six degrees of freedom. That means it can move freely about all three axes and also rotate about those axes. Any position, any orientation. Regardless of whether ships will have this kind of mobility, Copernicus requires it as not all moving structures will necessary be ships. In vanilla Minecraft, static blocks have zero degrees of freedom, and most entities have 4, being able to pivot about the (vertical) Y axis, or yaw.

It's entirely subjective, but if we consider the X axis to be forward, the Y to be up, and Z to be lateral motion to our right, then Yaw is rotating about the Y, Roll is about the X, and Pitch is about the Z. Together these are referred to as Euler Angles, and it's the easiest way to think of orientations. To determine which direction to pivot, you use what's called the right-hand rule. There are ton's of them but for rotation you make a thunbs-up with your hand, with the thumb pointing the the positive of the axis you want to rotate around, and the curve of your other finger is the direction of rotation.

That one's actually for the magnetic field around a current, but it's the same idea. Now, it's worth mentioning here that while this is standard in mathematics, and how openGL figures it, Notch made the yaw backwards, which goofs everything up. It's pretty easy to deal with once you know about it, but that's why I bring it up.

Now that we're clear on the terminology we can get back to orientation.
What you'll notice in 1st person video games is that when you look around, you also rotate your reference frame. For example, if you turn right and then look down, you are using yaw and pitch, only instead of your head tilting counterclockwise to the left, you look straight down. That's because you are pivoting about the Z axis in your own rotated reference frame. When you are doing this with all three rotations, the effect can be described with the gimbal analogy.

The longer you stare at it the weirder it gets. But the idea is that any orientation you can imagine can be represented with these three rotations, and that's pretty neat.
In vector math, rotations can be applied with a 3x3 rotation matrix. Each rotation has a distinct matrix, and through the magic of matrix multiplication, if you multiply each of them together you can create a new matrix that performs all the rotations as if they were done separately but in just one pass. Additionally, any time you want to apply new rotations, you can simply multiply them to the previous rotation matrix. Which is all fine and good. Except...

------------------------------------
Problems with Euler Angles
------------------------------------

The first is called Gimbal Lock, and it occurs when two of the gimbals reside in the same plane, losing you a degree of freedom.

Another problem is that moving from one orientation to another with this system can be quite complicated, depending on the nature of the movement, and it's even more difficult to make a clean transition from one to the other, involving changing the rotational speeds at rates defined by the states of the upper rotations. This becomes especially problematic if you are trying to do animation.
The final problem is with stability. Every time you multiply a rotation to the rotation matrix, a tiny bit of precision error is introduced, and at different rates for different parts of the matrix. If left alone long enough the matrix will lose its orthogonality, meaning that the rotation path is no longer spherical, and that's a difficult thing to correct.

----------------------------
Quaternions
----------------------------

To fix these problems, you have to abandon the idea of using Euler Angles altogether (right after I just made you read all about them, I know). Instead, we use the method that's been growing in popularity as of late: quaternions. What quaternions are is a kind of complicated subject, involving 4-dimensional space and imaginary coordinates. Fortunately for us, we only need to focus on a small subset called unit quaternions, who's magnitude is always 1, like a unit vector, and exists firmly in real-space.

A unit quaternion is the sum of a 3-dimensional vector and a scalar which together defines a single rotation about an arbitrary axis. Specifically, q = cos(Ɵ/n) + n*sin(Ɵ/2). (I would use the wikipedia version but black backgrounds don't agree with black on transparent images). So Ɵ is the rotation degree and n is the unit vector determining the rotational axis. Simple enough. for a 30 degree rotation about the y axis it would be cos(15) + [0, sin(15), 0]. You can also write it as the 4D vector [0, sin(15), 0, cos(15)], which is the way I prefer.

There are some notable advantages to quaternions. First, they don't suffer from gimbal lock, as you are free to rotate about any axis you like at any time. Second, you can fix the orthogonality error simply by re-normalizing the 4D vector form if it gets unstable. Finally, it's easy to transition from one quaternion to another with some fairly basic interpolation.

I won't go into the math for using quaternions, but it's all simple vector math. What I will say is that it's pretty fast. Multiplying two quaternions is done with 16 multiplications (additions are pretty insignificant cost-wise), where as the equivalent in matrix multiplication would take 27. Vector rotation takes 18 multiplications with quaternions and only 9 for matrices, but for 9 multiplications you can generate the rotation matrix for a quaternion. And for 18 multiplications, you can calculate all three axes for the new frame of reference, which is handy for Separating Axis Theorem.

================

That's what I've been learning about this past week. For the project, I am implementing two new classes, a matrix class which oddly enough is missing from the game, and an orientation class. The orientation class contains the base of a quaternion but will also have all the functionality you could possibly need for manipulating them, the idea being you will never have to deal with the quaternion directly, and can just apply rotations or convert to a matrix like normal. The matrix class is your typical fair, with support for any size of matrix, but will also contain special optimized functions for specific tasks like 3x3 rotation or 4x4 transformations, and of course all the functionality you would need to craft such matrices without ever having to touch the elements directly.

I'll probably make them all use floating point values by default, as error is easier to deal with for quaternions, and the performance of this part is critical for for Ship-World collisions.
Speaking of which, the new collision model is the subject of the next discussion, will I discuss ship-world collisions then? Definitely maybe.

As there are no major changes to the Copernicus roadmap, that's all I've got for this week, folks. Stay tuned.
Also let me know how I did this time. There were some concerns last time that I got too complicated and lost some people. I'm still getting a feel for how in-depth people would me to go.

fr0stbyte124 wrote:

Also let me know how I did this time. There were some concerns last time that I got too complicated and lost some people. I'm still getting a feel for how in-depth people would me to go.

I think you did great, and thanks for clearing Qs up, the last I heard of them was back when I worked on E2.

As for the complexity, I prefer as complicated as possible.

And a question, will collision include rotation due to momentium?

Exc, say a small ship collided with another at the side of the aft engine housing, would that ship spin around the y(verticle) axis?

Ok, that was confusing too...

Yes it will. There will also be block destruction. How it works specifically will depend on what other things we will be keeping track of, like mass, blast resistance of blocks, and things like antigravity if that comes into play.

Mini-update:

I was researching voxel rendering last night to try and figure out some tricks for increasing the render distance without hurting the framerate. Turns out it's rather difficult because, while you can simplify the geometry, there's not a good way to preserve the corresponding textures. But that's a problem for another day.

The reason I'm making a post about it is because I figured out another trick. Most of the geometry getting rendered actually comes from cave systems and other things you never see. In an attempt to get around this, Minecraft can optionally performs a GPU-based occlusion query check on each render chunk, which is what the Advanced OpenGL option does. The problem with it, though, is that it's really expensive due to the amount of primitives getting drawn. In fact, in my tests it needs to cull around 60% of all the chunks being rendered just to break even. And while messing with that, I figured out a new algorithm that should deliver pretty decent occlusion testing for really cheap.

The idea is that you estimate the lines-of-sight between the 6 faces of each render chunk and use that to figure out which chunks can possibly be visible from different angles. Then, by figuring the relative position of the camera, you can figure out which faces to test and expand from chunk to chunk along those faces with previously identified line-of-sight. It's pretty inaccurate, erring on the side of visibility, but it's footprint averages out to almost nothing, meaning it will run as smoothly as having occlusion culling off, but with around 50% culling above ground or 95% culling below.

I estimate that with this occlusion technique, playing on render distance "Far" will run comparable to vanilla "Normal" above ground, or somewhere between "Small" and "Tiny" in caves. I'm still working out all the possible optimizations (and there are a lot of them), and then there is getting everything to play nice with Java memory allocation (which I am still not fully comfortable with). But depending on how Mojang's optimization efforts go, I might make this a priority project, or even release it as a standalone mod.

fr0stbyte124 wrote:

Mini-update:

I was researching voxel rendering last night to try and figure out some tricks for increasing the render distance without hurting the framerate. Turns out it's rather difficult because, while you can simplify the geometry, there's not a good way to preserve the corresponding textures. But that's a problem for another day.

The reason I'm making a post about it is because I figured out another trick. Most of the geometry getting rendered actually comes from cave systems and other things you never see. In an attempt to get around this, Minecraft can optionally performs a GPU-based occlusion query check on each render chunk, which is what the Advanced OpenGL option does. The problem with it, though, is that it's really expensive due to the amount of primitives getting drawn. In fact, in my tests it needs to cull around 60% of all the chunks being rendered just to break even. And while messing with that, I figured out a new algorithm that should deliver pretty decent occlusion testing for really cheap.

The idea is that you estimate the lines-of-sight between the 6 faces of each render chunk and use that to figure out which chunks can possibly be visible from different angles. Then, by figuring the relative position of the camera, you can figure out which faces to test and expand from chunk to chunk along those faces with previously identified line-of-sight. It's pretty inaccurate, erring on the side of visibility, but it's footprint averages out to almost nothing, meaning it will run as smoothly as having occlusion culling off, but with around 50% culling above ground or 95% culling below.

I estimate that with this occlusion technique, playing on render distance "Far" will run comparable to vanilla "Normal" above ground, or somewhere between "Small" and "Tiny" in caves. I'm still working out all the possible optimizations (and there are a lot of them), and then there is getting everything to play nice with Java memory allocation (which I am still not fully comfortable with). But depending on how Mojang's optimization efforts go, I might make this a priority project, or even release it as a standalone mod.

Thats incredible! I always wondered why OpenGL culling was so slow. Ironic how people used to worry about crafts lagging badly, and now in all likelyhood Futurecraft will improve perfomance!

Oh, and on a unrelated note, whats this Area 51 I keep seeing mentioned around here?

Buggy1997123 wrote:

Oh, and on a unrelated note, whats this Area 51 I keep seeing mentioned around here?

It's the super top-secret developers board where we can discuss our latest work on the project. It's also pretty much vacant right now, since we are posting all our updates on the public boards.
I'll be using it in the future to distribute internal builds I don't want wandering off to the outside.

Very nice. Chalk another up for having encountered quaternions in gmod. Speaking of that though, you seem to be taking a similar approach to the gravity hull mod for said game, at least visually, what with the pocket dimension. My suggestion/question is, would it be possible to run player/entity collision from within the pocket dimension? Call the standard code from a dummy player, keep things grid-aligned and simple, then apply across to the actual player.

Conscript Gary wrote:

Very nice. Chalk another up for having encountered quaternions in gmod. Speaking of that though, you seem to be taking a similar approach to the gravity hull mod for said game, at least visually, what with the pocket dimension. My suggestion/question is, would it be possible to run player/entity collision from within the pocket dimension? Call the standard code from a dummy player, keep things grid-aligned and simple, then apply across to the actual player.

Yeah, the last I encountered quaternions was in gmod too, and I also thought it was similar too. What he's doing is pretty much exactly that too... Wow you are right a lot today.

Oh glory, Frostbite, are you telling me you can restore the game performance I had before 1.8? Hallelujah.

Very impressive work with the new system - I was actually reading about Euler in my Popular Science the other day... unfortunately I don't really have anything in the way of commentary to add about the rest of your work!

Can't make any assurances about the performance until I take a closer look at the render engine. Reducing chunks will help, but I haven't been able to identify the cause for the performance hit between 1.7 and 1.8. Persistent mobs is part of it, but only part. I'll keep you posted if I find anything interesting.

@Conscript Gary
I've never used Gary's Mod, but if they do the same thing, it's an encouraging sign. Entity-ship interaction works precisely the way you described. The entity bounding box and trajectory is translated into ship space, collision is applied, and then the new trajectory is returned and the next world space collisions are applied.

Wonderful. I can't post links yet, but yeah that's how they do it.
Although, that makes ships without artificial gravity a slight bit trickier, unless you can rotate the bounding box or I misunderstand the java analogue.

For now, all ships have to be aligned to earth gravity. Later, it will be possible to set local gravity by moving the player physically into the ship's dimension with invisible world portals and rendering the outer world as the fake one (to use that analogy. From a rendering standpoint there is little functional difference between one and the other). An added benefit of this is it will be possible to keep water out of the ship interior, allowing for submarines.

fr0stbyte124 wrote:

For now, all ships have to be aligned to earth gravity. Later, it will be possible to set local gravity by moving the player physically into the ship's dimension with invisible world portals and rendering the outer world as the fake one (to use that analogy. From a rendering standpoint there is little functional difference between one and the other). An added benefit of this is it will be possible to keep water out of the ship interior, allowing for submarines.

Why go through all that? The players viewpoint can be rotated, and so can World Renderers, so the only problems would be getting traces to work properly regardless of rotation and probably something else I don't realize.

Well it's not just the viewpoints. I want all entities to behave normally on ships without rewriting them all (so no special orientation code or anything), as that will be all the more difficult to maintain, especially with 3rd party mods.

In other news I did find something interesting with the render engine. Downloaded 1.9 pre4 for the fancy new pie chart thing, and it turns out that chunk updates (the number to the right of FPS) takes up a whopping 30% of all the processing in Minecraft. But I can't figure out why. To my knowledge, chunk updates only re-render modified chunk pieces when there is a block added or removed or a change in lighting. Even day-to-night doesn't trigger an update with the new lighting engine. Whatever it is, it's causing the largest framerate hit outside of actually rendering the world.

Also worth mentioning that when occlusion culling is on it takes 2-3 times more processing time than the actual rendering, which is great news for my new occlusion trick. If we can bring chunk updates back down to 1.7 levels, we should have no problem even doubling the view distance with normal rendering.

*edit*
Yep, the "needsUpdate" flag is always on for some reason, so it's doing constant re-rendering on every chunk as quickly as the limiter will allow. I wonder why...

fr0stbyte124 wrote:

Well it's not just the viewpoints. I want all entities to behave normally on ships without rewriting them all (so no special orientation code or anything), as that will be all the more difficult to maintain, especially with 3rd party mods.

In other news I did find something interesting with the render engine. Downloaded 1.9 pre4 for the fancy new pie chart thing, and it turns out that chunk updates (the number to the right of FPS) takes up a whopping 30% of all the processing in Minecraft. But I can't figure out why. To my knowledge, chunk updates only re-render modified chunk pieces when there is a block added or removed or a change in lighting. Even day-to-night doesn't trigger an update with the new lighting engine. Whatever it is, it's causing the largest framerate hit outside of actually rendering the world.

Also worth mentioning that when occlusion culling is on it takes 2-3 times more processing time than the actual rendering, which is great news for my new occlusion trick. If we can bring chunk updates back down to 1.7 levels, we should have no problem even doubling the view distance with normal rendering.

*edit*
Yep, the "needsUpdate" flag is always on for some reason, so it's doing constant re-rendering on every chunk as quickly as the limiter will allow. I wonder why...

The only reason I can think of is that the new "flickering lights" require updates to the chunk lighting. This is still (extremely) unlikely though...
It's most likely just a glitch, or Notch started new 1.8 coding for when it actually needed a chunk update, and didn't finish it.