Testing - models from C4D, physics and scripting for vehicle

I've done a little testing to see how well models created in Cinema 4D look in Unity. I exported them to .FBX and did some fiddling to work out how textures are handled. It's nothing brilliant, but I'm just pleased to have something working!

http://www.pdrummond.btinternet.co.uk/games/test1.html

If I can work out how to use the FX/Glass shader I'll add pretty glass to the building and jeep.

The steps at the back of the building are too high at the moment. You'll have to do some jumping to make it up to the balcony.

Next tasks is to work out scripting and physics for the jeep. Any suggestions are welcome! At the moment it's a model from C4D and cylinder primitives for the wheels. The wheels are connected to the body using hinge joints. It makes a nice bounce when it lands.

Move around using the default controls: arrow keys and space for jump.

I have to get back to the day job now, but hopefully I'll be able to keep working on this in my spare time.

 

Great work - congratulations....

We have a better FPS controller internally that can handle stairs a lot more properly. Hope to get it into 1.0.1

Hmm... I need to look at the glass shader.

 

Glad you like. Compliments are always welcome I'll hang on till the better FPS controller comes out rather than fiddling with stairs.
Any tips on the shaders would be appreciated.

 

Is there a minor weird thing going on when you bump into a wall you seem to climb up it a bit? It might be that the mass of the camera/players isn't high enough or, like during my building of the tutorial, the mesh on the walls of my platform wasn't fine enough and the player marble seemed to want to climb the walls a bit (because the sphere mesh was actually going into the empty areas of my wall mesh).

I later found out that primnitive collisions work much better than mesh collision for objects.

 

Mesh collisions are an inherently hard problem and should be avoided when necessary.

(To really appreciate how nasty it is, just think that to the computer an object is just a huge bucket of triangles. Then try to think of two huge bucket of triangles "meeting" in space, and trying to figure out what went inside what when and from which direction... it's nasty. Novodex does them surprisingly well, but still, it's not perfect).


Also, if you try to simulate a ball rolling as a mesh-collided object, you will probalby get "funny rolling" on even surfaces since you are really only approximating a ball shape with your mesh. This would happen on rough surfaces as well, but there it probably wouldn't be as noticable.

Btw. if you have a ball rolling into a wall and it has sufficient friction and speed, climbing up a wall is exactly what you can expect. Try it with any rubber ball.


If you ever need to know anything about rolling balls, just ask the master of the GooBall ball

 

I noticed the wall climbing too. I've just used the standard First Person Controller, so some tweaking is probably called for. At this stage I'm just experimenting so there will be LOTS of bugs!

I used a mesh collider for the scenery as the documentation suggests. How would you do it instead? At the moment the mesh for the scenery isn't particularly detailed. I modelled it using as few polygons as possible, did a quick bit of triangulation to keep Unity happy, then exported to FBX. The screenshot shows the mesh in Cinema 4D.

Hints and tips are gratefully received.

 

I have been finding that large triangles (with respect to what they are colliding with) in the physic engine are bad. For instance, I have a terrain with a car driving over it. (Made up of a few primitives) When I heavily optimized the mesh turning it into only a few large polygons, the car would sink into the terrain and not behave realistically. Subdividing the terrain fixed it.

I tried playing with the Physics/Dynamics settings, but none of them seemed to have an effect.

Maybe someone "in the know" could chime in about what is really going on here.

-Jon

 

What would you recommend for my example with the vehicle? The scenery uses a mesh collider and the jeep wheels use capsule colliders. The jeep body itself has a mesh collider attached. Would you recommend using a box collider instead? I think I tried that at one point and had some trouble, but that could have been because I hadn't got the wheel hinge joints right yet.

I'll try subdividing my scenery mesh and reimporting it.

Thanks for the feedback.

 

I'll try to work up a small test case. I did submit a bug but it was with that 90 meg file :roll: Whoops. . . it may have to wait until I can remove components again

-Jon

 

That's what I meant to say but typed it too fast :wink:

Mesh colliders for your playing field(s)/ground, objects and players should be done as one of the primitive colliders. The widget I'm working on saw a small but noticeable frame-per-second improvement by doing it this way.

 

Just a C4D to Unity question. Did you modle the entire scean in C4D and then import the whole thing into Unity. Or did you create each object that would go in the scean and then put it together in unity.

Also did you texture your scean in Unity or in C4D? I want to get started trying to get some stuff put together in C4D and into Unity but figured I would ask first. Jeff

(Also what is the Max polycount you could put in unity and still have it run on say an 800 Mhz G4 with 32 vRam?

 

Here's how we did in GooBall - it worked remarkably well:

1) Model one level completely in Maya (could just as well be C4D) tested that. This was in order to get a feel for the level.

2) Split out each entity in a seaparate Maya file. With 'entity', I mean a standalone item (the car would be a good example). It can contain multiple Unity GameObjects. The rule was: If you want to place it alone, it is a separate object. BookShelves, small rock formation, group of trees, etc...

3) Assemble levels in Unity. This makes it much faster to tweak in the long run than having to reexport each scene.

4) If you later want to add more gameobjects to a separate entity (say add some flowers to a tree formation), just modify the source C4D file. It will get added automatically across the project.

You UVMap your objects in C4D. When you're using more complex shaders (say bumpmapped), just modify the Unity Material add the bumpmap there. Then assign the photoshop files straight to the Unity object. When you save your photoshop file switch to Unity, it will automatically update the game (also flattening the file on import etc).

The trick is to NOT flatten export your .psd files to a separate .jpg or .tiff, so you only have one copy of each file laying around.
[/quote]

Depends. It's not really the number of scene objects polys that matter, but the number of on-screen polys. If you're making a top-down(ish) rpg style thingy, you have 20.000 poly's per screen area. As long as the camera doesn't make a shot along the ground, You'll be fine.

 

Here's how we did in GooBall - it worked remarkably well:

1) Model one level completely in Maya (could just as well be C4D) tested that. This was in order to get a feel for the level.

2) Split out each entity in a seaparate Maya file. With 'entity', I mean a standalone item (the car would be a good example). It can contain multiple Unity GameObjects. The rule was: If you want to place it alone, it is a separate object. BookShelves, small rock formation, group of trees, etc...

3) Assemble levels in Unity. This makes it much faster to tweak in the long run than having to reexport each scene.

4) If you later want to add more gameobjects to a separate entity (say add some flowers to a tree formation), just modify the source C4D file. It will get added automatically across the project.

You UVMap your objects in C4D. When you're using more complex shaders (say bumpmapped), just modify the Unity Material add the bumpmap there. Then assign the photoshop files straight to the Unity object. When you save your photoshop file switch to Unity, it will automatically update the game (also flattening the file on import etc).

The trick is to NOT flatten export your .psd files to a separate .jpg or .tiff, so you only have one copy of each file laying around.
[/quote]

Depends. It's not really the number of scene objects polys that matter, but the number of on-screen polys. If you're making a top-down(ish) rpg style thingy, you have 20.000 poly's per screen area. As long as the camera doesn't make a shot along the ground, You'll be fine.

 

Here's how we did in GooBall - it worked remarkably well:

1) Model one level completely in Maya (could just as well be C4D) tested that. This was in order to get a feel for the level.

2) Split out each entity in a seaparate Maya file. With 'entity', I mean a standalone item (the car would be a good example). It can contain multiple Unity GameObjects. The rule was: If you want to place it alone, it is a separate object. BookShelves, small rock formation, group of trees, etc...

3) Assemble levels in Unity. This makes it much faster to tweak in the long run than having to reexport each scene.

4) If you later want to add more gameobjects to a separate entity (say add some flowers to a tree formation), just modify the source C4D file. It will get added automatically across the project.

You UVMap your objects in C4D. When you're using more complex shaders (say bumpmapped), just modify the Unity Material add the bumpmap there. Then assign the photoshop files straight to the Unity object. When you save your photoshop file switch to Unity, it will automatically update the game (also flattening the file on import etc).

The trick is to NOT flatten export your .psd files to a separate .jpg or .tiff, so you only have one copy of each file laying around.
[/quote]

Depends. It's not really the number of scene objects polys that matter, but the number of on-screen polys. If you're making a top-down(ish) rpg style thingy, you have 20.000 poly's per screen area. As long as the camera doesn't make a shot along the ground, You'll be fine.

 

I was actualy just asking about that system range as an idea of what I would like for a minimum requirement. My two systems are:

Power Mac G5 Dual 2.5 Ghz with Radeon 9800 XT Pro 256
iMac G5 Single 2. Ghz with 128 (not sure what card)

What polycount could I get by with on these more powerfull macines?
Thanks for the quick reply. Jeff

 

The building was created as a single polygon model in Cinema 4D. I also textured it there, making sure the name of the internal Cinema 4D texture matched the filename (minus .tif extension) of the bitmap used. For example, the main texture used for the walls is called 'stone1' in C4D and uses a file called 'stone1.tif' for the colour channel, and 'stone1 bump.tif' for the bump. I applied the textures to the appropriate polygon selections. (It doesn't matter what the polygon selections are called. Give them sensible names in C4D for ease of use, but they'll show up as Element 0, Element 1 etc. in Unity.)

I then exported the model to FBX and imported it into Unity by putting the .fbx file and the colour and bump textures in the project assets folder. The model and textures will show up after Unity rescans the assets. A quick visit to the Assets menu / Import Settings option for each of the textures allowed me to change the Texture Format to 24 bit RGB and generate a bump map where appropriate. Then, dragging each main texture file onto its parent model created a material with the same name. For example, dragging 'stone1.tif' onto the building model created a material called stone1. I was then able to edit this material, changing it to use the Bumped Specular shader. I could then drag the 'stone 1 bump.tif' file onto the bump slot. (I've attached a screenshot)

The vehicle was modelled in the same way, so it's a separate entity inside Unity. When I feel more confident with Unity, and start planning things properly, I'll break some parts of the scenery down into separate models so I can reuse them in Unity. For example, creating sections of a building as a model which can be duplicated and joined together in Unity to create a larger whole.

I create the textures in Photoshop, using multiple layer groups for the colour and bump channels. I save flattened tif versions when I'm happy with the final result and use these on the models. (I know I could use the actual Photoshop files as the live textures, but I use a single file to create both the colour and bump textures. I also keep uv map guides on the top layers and I'd probably forget to turn these off and end up with wierd looking textures in my game. Saving flattened, separate files is easier for me.)

I hope this is useful. Some of this was worked out through trial and error, so I've no doubt chosen the most inefficient way to do it! Tips from the experts are appreciated.

 

Thanks so much for the detailed explenation, hopefuly I can get something into Unity today. If I do I'll let you know. Jeff

 

I'm glad it was useful. It will be good to see what you come up with.

 

I was playing around with the test you linked to in the first post of this topic, and it looks pretty cool.

The two problem's I see (not yours, I think, more unity issues) are that:

A) Unity doesn't fully capture keystrokes in webplayer mode, so pressing the up key scrolls the window up, and pressing down scrolls back down. This causes the game to disappear for a moment as the Unity logo appears, then it returns.

B) The other problem I seem to have with every one of the FPS script games, including some tests of my own back in the beta, and that is that the screen doesn't follow the mouse very well. The Unity viewpoint tracks much slower them my mouse movement, which is especially a large problem in a webplayer app, but is also irritating fullscreen. I'm not sure if this is an issue with the script, or possibly something due to me having multi-monitors. Is there a way for Unity to lock the mouse in the center for something like a webplayer app using the mouse? That way it won't be going all over the place (which leads to clicks in another app sometimes)

Sorry for getting a touch off topic there. Looking great, I look forward to taking a glance at it when textured.

 

The problem with capturing mouse in the web player is that then somebody evil could use it to make the most annoying banner advert ever...

We could look into capturing mouse in Dashboard widget. (I'm taking the fact that Apple has put up a warning to mean that you're free to do pretty much what you want there).

Please file bugs on these issues, so we remember to look into them.

 

The web player has that "go fullscreen" option in the contextual menu, too. You can control-click to get at it.

Presumably you could then set Screen.showCursor to false and get the mouse hidden and working proper for an FPS type thing. Haven't tried it, but it should work.

-Jon

 

Yeah... Exactly - we had a scripting way to accomplish that, but had to remove it. So now, if the user wants fullscreen they can get it (if they can find it, that is)