next »

[gimymblert]

what's the hardest part?

[zede05]

what's the hardest part?

Just a general balance of resources and game efficiency. Since this is a voxel game in the Unity engine, the 32bit ram limit is really forcing us to do a lot of things that we don't want to do on the art side, downgrading models and textures. On the programming side as well, we're running into problems we never really thought of when we first set out to do this game; such as, do we use character controllers or rigid bodies for mobs? Normally, character controllers would be fine, since it's a lot more efficient. But, due to the fact PE allows for player made vehicles, running into a character controller on a vehicle forces the vehicle to completely stop on a dime. So this ends up being an efficiency vs feel type of problem.

But yeah, stuff like that.

[gimymblert]

Oh! Wait does that mean you need lots of ram to play the game anyway? That mean it won't run on most ram starved machine? what's the minimal cap?

I know what you mean for controller, it give me hard time too the way it work on unity. It looks like you use the standard physx implementation (faster dev) instead of overriding it but keep it as "listener" (slower dev) which is comprehensible for a project of this scale that is not based on precise 6DOF platformer movement like mine that must run on the unsupported flash preview (crazy).

However looks great, too bad I can't run it right now, but I have been following this since the beginning!

[zede05]

Well, right now, a 32bit os will probably run out of ram in 20 min at the highest settings, 40 min at the lowest. We're planning to but out a 32bit version with low res textures and such, but Unity's garbage collecting probably has some bugs where it doesn't do it when we ask it to, so some assets in memory starts adding up over time.

[gimymblert]

Good to know so I never get there XD
I wonder if it's truly unity or mono that is the source of the matter ...

[zede05]

Some new NPC concept art. We're now working on the western part of the world map. Basically the canyon and the desert areas. If you followed the thread, you're probably wondering why we're still doing them since we already showed off them before. Well, it's more like a redo, we have better tools now, so we're adding in a lot more detail.







We're completely redoing the creation system, it'll now allow players to import their own textures, decals, turn, copy, paste, angled edges, smoothing, beveling...basically almost everything players asked for. It's also getting really close to being too complicated for normal players  . We're also adding in the blocky/angle building for the overworld with a resolution of 1/4 meter.

[zede05]

Been meeting with animators and designers about how to make our combat flow better. So far, we've had the problem of trying to have every animation mix with other animations like running and fighting at the same time. The problem with this approach is, while the top half is swinging a sword, the bottom half plays the running animation and doesn't have the same weight associated with the swing animation. So it looks stiff and weird.

So after some discussion, we decided to completely scrap the mix animation idea, we just don't have the capability yet to make animations like in Uncharted or Overgrowth, I guess. Instead, we'll go the traditional route and have something like in Star Ocean, which is probably more fitting for this game anyway, as far as combat and style are concerned.

[zede05]

Here are a couple of screens showing our work in progress random town generator for adventure mode.

[zede05]

Haven't posted in a while, been super busy working on the latest build. We rewrote a lot of code so that things are a bit more future-proof. Also been adding and changing a lot of art assets. I've said it in this thread before, but, dang, making a 3D open world game is hard. Things are constantly needing to be optimized, so we're being forced to continuously rewrite a lot of the code. Sure, we're learning stuff, but it's taking chunks and chunks of time off our schedule.

Here are the old forest trees in the game:



Here are the new models:

[eobet]

Wow. Huge improvement!

But... that's very earth like. Wasn't it more alien before?

[zede05]

The tree structures are still the same overall design, just more natural layouts to the way the model's made and more earthly colors. So the place still looks pretty alien. 

[zede05]

The jetpack 

[zede05]

Some shots of the canyon area. This place was hard to make, since everything was placed in manually. We have a very primitive terrain editor that lets us put in voxel objects we create in another editor, so all the ledges in the screens are premade and inserted. Since Unity is only 32 bit, I pretty much had to save every 10-20 min and restart since each of those voxel piece I put in take a huge chunk of memory. Oh well, the effort was worth it. 







More screens here: http://planetexplorers.pathea.net/new-redstone-canyon-screens/

[Quarry]

These look absolutely gorgeous!

[zede05]

Thanks!

Here's a screen shot from the desert biome. Textures sure take up a lot of space in Unity. We're trying to optimize, but right now, the desert scene is taking 600MB of ram just from textures. 

[gimymblert]

http://artisaverb.info/DitchingDiffuse.html
here !
also maybe going pbr with vertex coloring, constant spec , rg normal + roughness packed in ... and atlas
http://www.fxguide.com/featured/game-environments-parta-remember-me-rendering/
http://www.altdevblogaday.com/2011/08/23/shader-code-for-physically-based-lighting/
less split in texture

[zede05]

Oh yeah, we could actually try using procedural maps...and we did buy a license of Substance when we first started PE. I was hoping we could do full seasons and such with procedural textures, but procedural doesn't work on voxels yet (when we were nailing down the tech), well, not too well, since we have all of our terrain/voxel textures on atlases, but they should work well for buildings. I'll have to dig into it, thanks for point it out, completely forgot about it.

[SleepyRhino]

Atmosphere in the different areas looks bang on especially the desert biome.

Good job

[zede05]

Does anyone else using Unity have crashes with the Win64 builds? We keep on getting a crash caused by Opcode::HybridOBBCollider::Collide + 0x64c 

[gimymblert]

Well What I said had nothing to do with procedural


The technique outline in that paper is called procedural but is not that at all, it's more a way to artistically compressed/optimize texture using gradient and one channel per diffuse instead of a full rgba. So each of the rgba channel store a full texture dividing the cost per 4. And he goes further by using an extra texture using similar rgba packing with some common "noise brush" to further compressed data by reusing pattern. For exemple a rocky pattern can be use for a tree with a the right gradiant and a UV stretch at a shader level. PBR (physically based rendering) further lower the cost and give better lighting by generalizing material, since a lot of time there is a dominant color using vertex color to add low frequency variation. Just by looking at the image you post earlier you can greatly reduce the load by a factor 4 at worst and likely by a factor 10 while having more details in the end!