Collaborative Project: MARS MINER

[Hatsen]

[QUOTE=Smashmaster;34274460]It looks good, but I disagree that you should stick to cubes. Tell me, how would prospecting rovers work on cubes? Besides, it'll help later to differentiate from Minecraft early on. You don't want people labeling this 'Minecraft in space.'[/QUOTE]
Maybe block-wise we could do something like benji2015 is doing, hell I don't know.

[QUOTE=benji2015;34235467][media]http://www.youtube.com/watch?v=1M-viXDlTR0&feature=youtu.be[/media]

The terrain outside of the lighted area was a dark blue before recording.. meh

I plan on having worlds wrap around later so you can walk all the way around the world.. not sure how that's going to work though

[editline]16 January 2012[/editline]

Got saving and loading working.

Hadn't thought about that.. definitely going to do that now though.[/QUOTE]

[Tamschi]

Is the framerate higher? I just checked if it works and I think I'm moving faster than before.

[Ziks]

Not sure what I did to cause that and when it started, but it seems faster for me too.

[noctune9]

Could be really tempted to join in on this. I got a good amount of C# experience and have used OpenTK a bit.

[QUOTE=Robber;34208714]Why not use C# as the scripting language? It's a .NET project after all.[/QUOTE]

Why not just use managed .dll's? AFAIK, the C# code provider is not a part of .Net, but is Microsoft specific. If you just loaded .dll's directly and mounted them in the program, you could use whatever language you wanted.

[Ziks]

With my RPG project the entities (apart from the player) were scripted in C#. If I recall correctly a guy ran it on Linux with Mono fine. I don't know how we would contain malicious code if we were to use .dlls, but I can see the benefit in terms of using any .NET language.

Also feel free to join, the more the merrier. I think networking is next, how much experience do you have with that? Alternatively the map generator could use some improving (making craters, caves, etc). There will be much more to do when the networking and entity frameworks are done.

[BlkDucky]

is there anything for an incompetent programmer that doesn't know C# or OpenTK to do?

[editline]18th January 2012[/editline]

I'd give you my card, but I don't have one

[Smashmaster]

[QUOTE=Ziks;34274469]Models and stuff won't be cubes, and geometry will eventually (hopefully) have sloped tiles to smooth terrain. I imagined models to be quite low poly but a bit cartoonishly styled so the low polygon count doesn't look out of place.

I was referring to having gridlines.[/QUOTE]

Sloped tiles is all I was talking about, really. Marching tetrahedrons might do the trick.

[url]http://en.wikipedia.org/wiki/Marching_tetrahedrons[/url]

EDIT: And here's an article with code.

[url]http://paulbourke.net/geometry/polygonise/#tetra[/url]

[Ziks]

I hope to get sloped tiles done this week, the main problem is that we're currently using quads and rendering a triangle by putting two vertices in the same position would feel a bit naughty. I [I]might[/I] be able to bring myself to do it.

[Smashmaster]

[QUOTE=Ziks;34281443]I hope to get sloped tiles done this week, the main problem is that we're currently using quads and rendering a triangle by putting two vertices in the same position would feel a bit naughty. I [I]might[/I] be able to bring myself to do it.[/QUOTE]

What method are you thinking about trying?

[ROBO_DONUT]

[QUOTE=Ziks;34281443]I hope to get sloped tiles done this week, the main problem is that we're currently using quads and rendering a triangle by putting two vertices in the same position would feel a bit naughty. I [I]might[/I] be able to bring myself to do it.[/QUOTE]
Why can't you render triangles, exactly???

[Darwin226]

[QUOTE=ROBO_DONUT;34281558]Why can't you render triangles, exactly???[/QUOTE]

Besides. Quads are deprecated.

[Ziks]

Since I'll also have to know the shape of the block for physics as well as rendering, I can't just find out the shape when I'm generating vertex data. I'll probably have the world generator deciding what blocks are slanted, and then only have floor slants. I've allowed block types to have "subtypes", so I'll have 14 floor subtypes for each slant combination for each type of block that can be sloped.

I'll move the whole thing to use triangles too.

[Deco Da Man]

[QUOTE=Ziks;34288502]Since I'll also have to know the shape of the block for physics as well as rendering, I can't just find out the shape when I'm generating vertex data. I'll probably have the world generator deciding what blocks are slanted, and then only have floor slants. I've allowed block types to have "subtypes", so I'll have 14 floor subtypes for each slant combination for each type of block that can be sloped.

I'll move the whole thing to use triangles too.[/QUOTE]

Would you mind experimenting with another potential solution?

Try giving each block an offset vector for the Top Left Forward corner.
The structure:

struct Block {
    Uint116 type;
    float x, y, z; // Or whatever other type is suitable
}

(perhaps a short would be smaller)

The offset would go from -BlockSize/2 to +BlockSize/2
When rendering, use your GetNeighbour functions to find the offset for each corner of the cube, and render warped faces appropriately.

The benefit of this method is that it allows for plenty of unique shapes; with some interpolation in a shader, you could render very smooth terrain.
It also allows for constructions to be placed freely, with no restriction to the grid system.
As for mining, you can gradually shift the offsets of the face being struck in an appropriate direction to decrease the volume of the cube.
It works (well, at least I think it would) for both top-level terrain subterranean caverns.

There are several issues, however - most importantly: rendering individual cubes requires finding every single neighbour (which means, more often than not, stepping upwards in the octree (bad for optimisation)).
The math is also [b]extremely[/b] difficult at times. I asked a university math professor for assistance in forming an equation to calculate the area of an irregular hexahedron (a warped cube). Even with the restriction that it could not be concave, he struggled to find a solution (mind you, he was a bit sleep deprived).
Memory usage is also an issue: it would increase the size by at least a byte. Perhaps use 15 bits for the block type and 3 bits for each offset dimension? That offers 0 to 4 in each direction, with an additional "special state" for negative zero.
I'm not sure how viable this is in C#, or in GLSL... but if working with such arbitrary bit sizes isn't an issue, space shouldn't be much of a concern.

If you are feeling adventurous, would you mind trying this out? I would love to do it myself, but I have little free time for extra projects.
Even the smallest exploration into this concept would be most appreciated :)

[Ziks]

I'll give it a shot this evening. It would mean a lot more memory usage though, because blocks don't currently store any position or size information.

[editline]19th January 2012[/editline]

Also there may be problems with neighbours that are bigger than the block you're finding vertex data for.

[Tamschi]

Instead of computing the surface every frame, it's probably easier to use marching cubes on the octree and then send the final mesh to the graphics card once.

I think it's possible to adapt the algorithm to different materials by running it for each material and omitting faces if the adjacent space is solid.

The individual meshes would work as collision mesh for Jitter, too.

[Ziks]

We're currently only computing and sending the mesh when the octree is altered, so I would do the same when finding slopes.

[Ziks]

[QUOTE=Deco Da Man;34289039]Would you mind experimenting with another potential solution?

-snip-[/QUOTE]

It just doesn't work with irregularly sized leaves in the tree. It would be fine if every leaf was 1x1x1 block big, but then that would render the octree pointless. We need an effect which would work without exposing the shape of the tree. Anyway I'm going to go off and randomly start making a model designer to use in this.

[Ziks]

Finally I have internet on my main PC. Commendably they were only two days late. I've been working on a model system to use with entities and non-cubic blocks.

[noctune9]

Hmm.. Doesn't seem to run on my machine. It complains about TexParameterI missing in opengl32.dll, which seems odd since it's a OpenGL 3.0 function and I have OpenGL 3.2 on this machine.

Just found it with OpenGL extension viewer, the function is there so I can't really understand why it wouldn't work.

[zenby]

Got the same/a similar error.

System.EntryPointNotFoundException was unhandled
  Message=Unable to find an entry point named 'glTexParameterIiv' in DLL 'opengl32.dll'.
  Source=OpenTK
  TypeName=""
  StackTrace:
       at OpenTK.Graphics.OpenGL.GL.Core.TexParameterIiv(TextureTarget target, TextureParameterName pname, Int32* params)
       at OpenTK.Graphics.OpenGL.GL.TexParameterI(TextureTarget target, TextureParameterName pname, Int32[] params)
       at MarsMiner.Client.Graphics.GeometryShader.GenerateTileMap() in C:\Users\----\Downloads\Metapyziks-MarsMiner-6a62551\Metapyziks-MarsMiner-6a62551\MarsMiner.Client\Graphics\GeometryShader.cs:line 272
       at MarsMiner.MarsMinerWindow.OnLoad(EventArgs e) in C:\Users\----\Downloads\Metapyziks-MarsMiner-6a62551\Metapyziks-MarsMiner-6a62551\MarsMiner\MarsMinerWindow.cs:line 91
       at OpenTK.GameWindow.OnLoadInternal(EventArgs e)
       at OpenTK.GameWindow.Run(Double updates_per_second, Double frames_per_second)
       at OpenTK.GameWindow.Run(Double updateRate)
       at MarsMiner.Program.Main(String[] args) in C:\Users\----\Downloads\Metapyziks-MarsMiner-6a62551\Metapyziks-MarsMiner-6a62551\MarsMiner\Program.cs:line 39
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: 

[Ziks]

I'll see what I can do, hold on

[editline]21st January 2012[/editline]

Try it now (I deleted the I's).

[zenby]

[quote]OpenGL hates your guts: InvalidEnum[/quote]

:C

[Ziks]

Does you card support Texture2DArrays?

[Tamschi]

Wich is better: A more or less global SaveManager that must be disposed when the program closes or GameSaves that must be flushed/waited for before it can be destroyed?

[Ziks]

What would the pros / cons of each be?

I'm sorry for not working on this much over the last few days, had a pair of assignments and the task of looking for a house taking up my time. I'm almost finished with sloped terrain.

[Tamschi]

The saves will be asynchronous, so there's a queue with changesets that is written to disk in background. The problem is that finalizers are killed after a few seconds (in addition to invalid references), so I don't think I can auto-flush the queue once all references are lost.

The GameSave is the same for both solutions, but if there's a SaveManager the GameSaves don't have to be closed synchronously.
The SaveManager would hold the reference while the GameSave is busy and block the disposing thread until all GameSaves are flushed.

There [I]may[/I] be a race condition with chunk loading after a world change if the old world was saving while a new chunk got into range shortly before the change if the chunk loaded event is bound to a singleton though.

[TomsonTom]

Just a small rant: if you really want Lua scripting, you won't get Lua interface for C# working on Linux. There's currently no Lua interface for C# that can be ran under Mono (unless you make one yourselves). If you found something, then please tell me, but right now you've got three options: no Lua / no Linux support / spend a month making your own interface working on Linux. :)

[Ziks]

I don't think having Lua is worth sacrificing Linux support, so we'll probably go with C# scripting.

[naelstrof]

We've already sacrificed Linux support by using C#. I see no problem with adding lua.

[Ziks]

Doesn't it run with Mono?