Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Scelly9]

Perfect tiling! Not one seam in sight.

That is VERY nice.

One request for the game as a whole: I note that in the document on Google, it says that some metals and alloys are better or worse than others. I'd like to keep the relative strength as close to reality as possible. I don't care about any deviations from reality with steam power, but metallurgy is a little more important to me.

I agree. Its more fun that way, also more !!FUN!!

[dreadmullet]

A object should obviously not be able to exist inside a solid, nor a slope. It should also start falling if it is in a cell where there is no solid or slope beneath. If the object moves into a slope, then it should move one voxel up, assuming that there is free space there.

If I understand you correctly, you're thinking that EVERYTHING should be represented as voxels, including robots. I don't think this should be the case. Are you suggesting that the robots move one tile at a time, instantly? That would look terrible. I was thinking that the terrain would have a mesh collider and the robots would use capsule colliders or something. It sounds complicated, but Unity makes everything easier, especially moving characters around.

[DrPoo]

Yeah, Exams here as well. Good luck with them.

You too!

[Kofthefens]

2. Malloc- I'm going to be working on pathing soon. I'm not really sure what the code for your voxels looks like, so could you give me an idea of how to tell if a robot is colliding with one?

For now each voxels is represented very lowlevel by a 32bit integer, which represents what state the voxel is in. I have only used the first 5 bits for now.
If no bits are set, it's an empty cell.
If the first bit is set, then it's a solid.
If one of the next four bits are set( Values 2 to 16 ), the voxel represents a slope.
Where each individual bit represents one of four slopes, basically 2(x+1,z+1) 4(x+1,z-1) 8(x-1,z+1) 16( x-1, z-1).
That means if the slope value is 24 then 8 and 16 are set, and the slope will go x-1 to x+1. If the value is 6 it will go from x+1 to x-1 and so on.

A object should obviously not be able to exist inside a solid, nor a slope. It should also start falling if it is in a cell where there is no solid or slope beneath. If the object moves into a slope, then it should move one voxel up, assuming that there is free space there.

I didn't have a lot of time yesterday, so I didn't do enough work to show really. I did however do some refactoring of code to be much more consistent, it also exposed some corner cases where the mesh generator would fail which I then fixed. There is still a few rare cases where it will fail to generate the right geometry. It's an ongoing process and I think it's good enough to, start on the more meaty game related stuff today.

So if(voxel.noBitsSet() {
canBeCollidedWith = true;
Or some such. This would be calculated by the robot as it went, so that it wouldn't use too much memory

A object should obviously not be able to exist inside a solid, nor a slope. It should also start falling if it is in a cell where there is no solid or slope beneath. If the object moves into a slope, then it should move one voxel up, assuming that there is free space there.

If I understand you correctly, you're thinking that EVERYTHING should be represented as voxels, including robots. I don't think this should be the case. Are you suggesting that the robots move one tile at a time, instantly? That would look terrible. I was thinking that the terrain would have a mesh collider and the robots would use capsule colliders or something. It sounds complicated, but Unity makes everything easier, especially moving characters around.

I think mesh colliders are the way to go. I'll have to learn some more Unity I guess...

[Araph]

Query related to the weekly-meeting-thingy idea: did that ever get decided on? It seems like it'd be a convenient way to keep the project moving forward. I know that right now we've got our two programmers working on pathing and terrain, but I think that we should finalize the plans for the game so that anybody who can help and wants to help knows what to do.

[Kofthefens]

People have agreed to it, but no meeting has been set up. Virex set up the meeting last time, would you be willing to set it up again? (On Saturday, preferably)

[Araph]

I'd be happy to set it up; what medium are we using to communicate? And does sometime this Saturday work for everyone?

Spoiler: First Draft of Wood Texture (click to show/hide)

This is my first attempt at wood. There's a visible grain, those little swirly knot things, the colors are fairly accurate. I'm not sure what to do about tiling, though; do the wood textures need to be repeatable? Also those darker patches at the top and bottom, I'm not sure what's up with them. Anything else major that needs fixing with it so far?

[Kofthefens]

I imagine some IM chat room, but I'm not really sure. Good job on the wood.

[dreadmullet]

I declare a meeting on Saturday 20:00 GMT at irc://irc.newnet.net/CodeJam (the last place the conference was at). Hopefully it will allow us to solidify all game concepts, as well as put up a list of things to do.


@Araph: Not bad. It's very slightly too yellow, and very slightly too light. Easy things to change. What I'm more worried about is the lack of any actual images. It looks completely procedural. I highly recommend using textures from www.CGTextures.com. Using procedural textures is good enough for some things, but using actual photographs makes the texture much more believeable, and CG Textures is the best thing ever.

But there's just one thing. The license for CG Textures doesn't cover open source projects, and this project is obviously open source. However, I think if the textures are modified enough, then it's okay to use them. Not sure, though.

Or we could only use procedural textures and call it the art style...

Anyways, about the wood's tiling: it only needs to be tileable along the longest direction, or in this case the Y axis. Right now your texture doesn't tile well at all along the Y axis. I would also make the texture 512x1024, since it will probably only be used for planks and similar things.

[malloc]

So if(voxel.noBitsSet() {
canBeCollidedWith = true;
Or some such. This would be calculated by the robot as it went, so that it wouldn't use too much memory

more like:

Code: [Select]

if (GetVoxel(int x, int y, int z) == 0) //Position free

Honestly, I still might change it a bit. As it is now i try to untangle the lowlevel voxel related code and keep it seperate from the terrain more highlevel terrain object.

If I understand you correctly [...]

No you misunderstood. The voxel represent a bit of terrain. But it should easily be used as a AABB collision mesh if need be. I could even write the collision code for them myself. All I was saying is that game objects should not be inside solid cells. But we have not decided on any of that as of yet.
I implemented a form of triplaner texture mapping by the way, basically I project UVs onto the axis plane that they are most orthogonal with, with more weighting on the Y axis.
It took a little longer than expected. Not because I did it wrong, but because I made a silly assumption when I started, and forgot all about it when I was finished. I spend a few hours breaking my head on why the heck my math was not working. I even went as far as rewriting the whole thing using elementary arithmetics, thinking Unity used some vector notation I was not familiar with. Sufficient to say I feel stupid and tired now.

We really need to discuss how we are going to do texturing. Are we going for same approach as Minecraft with a single atlas texture? It's a very efficient way of doing things as it eliminates the need for texture swapping, and as the UVs are generated now it could easily be implemented. Or do we use multiple textures which is much slower. But it might make it a little easier to develop for the game.

Also, is there any reason why the textures are 1024x1024? Even with Unitys super optimized compression, one texture still take up almost one megabyte of graphics memory. It becomes really boggeling when looking at how few features the dirt textures really had. I could resize it to 256x256 no visible difference even at close range.

My suggestions is add more features to the textures. In the end random noise is not pleasing to look at.

[GalenEvil]

If you can add in different sorts of bump-mapping for the textures there wouldn't be:
a) not a lot of just random noise, which I agree is not appealing to look at
b) it could add variety while not increasing dramatically the number of textures used

You are completely right on the size of the textures question. 1024x1024 is huge any way that you look at it. If we could get the textures down to that 256x256 it would take up I guess about 1/8th the memory footprint? or is that 1/16th the memory footprint? I don't remember at the moment...

If we are able to upgrade the texture implementations of Unity I might be able to find a way to get it to do an n-texture optimization if it is currently slow enough to be noticeable. I will need to delve into Unity to figure it out but I should be able to get it downloaded tomorrow or the day after (assuming I can visit a library within that timeframe).

If we go with procedurally generated textures then I might be able to do some sort of optimization on those as well if we can get a nice looking procedural texture generation method established.

I do have a small question: Can the Unity engine play with C++ in a civil manner?
If it is able to the I can maybe add in some things to a prototype engine I am working on to make some of the textures based on information given to it. Right now it relies on whole textures but it shouldn't be too difficult to incorporate some procedural texture methods if I know how to make them. I will dive into some of my c++ stuff and come up with an answer to this on my own if needed, as well as a way to communicate Unity -> procTexture - > Unity if iit is possible to do so in a reliable way.

I might have some AABB collision stuff in the engine written in C++ that I could send you tomorrow, assuming that I can find it and that you can convert it to Unity's needs.

I don't think that I have anymore to add at this moment, as it has taken me more than a half hour to just type this up (stupdi alcohol) so I will end it here >.>

[Virex]

People have agreed to it, but no meeting has been set up. Virex set up the meeting last time, would you be willing to set it up again? (On Saturday, preferably)

I won't be availible this weekend, unfortunately.

[Kofthefens]

I declare a meeting on Saturday 20:00 GMT at irc://irc.newnet.net/CodeJam (the last place the conference was at). Hopefully it will allow us to solidify all game concepts, as well as put up a list of things to do.

I feel a little silly, but how do I get on to it?

malloc- thanks. I'll see what stuff I can do this afternoon.

[malloc]

I do have a small question: Can the Unity engine play with C++ in a civil manner?

Unity runs c#, which can link to dynamic libraries. But it will break any sort of cross platform compatibility we have from using Unity. I don't think it is actually possible to optimize texture storage in Unity. They already have optimized the textures to take up less than a forth of what they would have in raw format. A 1024x1024 RGBA texture uses 4 megabytes normally in uncompressed format. They made it use up about 700 kb.

I really like the procedural texture idea, it would make for some interesting features. If you are up for creating the system, I won't stop you, and we can easily adopt it. But I won't delve into it myself, as I really think it is a lot for work.

I might have some AABB collision stuff in the engine written in C++ that I could send you tomorrow, assuming that I can find it and that you can convert it to Unity's needs.

I am fully capable of writing my own AABB collision code. But mine is for the time being limited to a vanilla geometric approach, as I have yet to delve into more advanced geometry. If you have a more optimized approach that, for an example makes use of "plucker coordinates", then I would love to see your code. I could even convert it to work with the voxels.

Anyway guys. I am really in the mood for coding, and shalt therefore devout the rest of the night/morning to the game. I will finish refactoring, add the ability to add materials and different events to the voxels. I will go ahead and use texture atlas mapping, but keep it relatively separated in case we do not want to use it.

[DrPoo]

Oh, also, what about water physics how will theese work? Will the map be finite or "infinite"?