Vehicle Design Questions

[WickedPenguin]

I'm working on a new "project" for UT3, and I have a couple of question regarding some of the technical aspects:

1) I noticed in one of the screenshots that there seemed to be a couple of guys on hoverboards being pulled by a Manta. Do the "tow ropes" link to a particular bone on the skeleton, or just to the "root" bone? Is there a variable in the Uscript?

2) Given that we've now got both human and alien races - and their accompanying vehicles - how many skins do we need to make for each vehicle? Is it still just red and blue like in Ut2004, or do we need to factor more of them in there?

3) Is it safe to assume that, from a coding standpoint, we'll be able to extend existing classes and build off of them?

4) What coding tools will there be? Is WotGreal usable, or is there some totally new scripting/compiling system built into UT3?

5) Will skeletal meshes, static meshes, and animations exported with older (Maya 6 or 7) versions of ActorX work with the UT3 Editor?

6) How many polygons/triangles is the highest polygon vehicle in UT3? I remember UT2004's Hellbender was the heaviest in that game, at around 6000 triangles.

EDIT: In the meantime, here's a revised version of that missile I posted a couple of weeks ago. It's not perfect yet, but I've revised the texture and normal map.

http://www.wickedpenguin.com/ue3/images/Missile2_Large.png

[Blaaguuu]

I think most of those questions are technical issues that someone from Epic would have to, but probably wont answer... So we will have to wait for the game first. But I will try to answer a couple:

3) It would be pretty absurd if we couldn't extend existing classes for mods... I'm sure that will be possible.

5) Someone from Epic has said that UED still imports .ASE files, so anything previously made in that format should work fine.

[JaFO]

That depends on how the game was written and what the internals structures/classes are like Blaaguu. Consider how difficult it was to add in support for 3+ teams, because most of the default code only worked for 2 teams. Some of the changes were easier when compared to UT'99, but some (like the multi-team support) weren't. I do hope that UT3's classes and structure will make it easier to add or change the vehicles without causing problems for mutators. Time will tell ...

[geodav]

having read stuff for roboblitz i think the file formats haven't changed, it's just a case of adding normal maps maybe speculars as well, where poly counts maybe higher theres still no point of wasting them

[WickedPenguin]

having read stuff for roboblitz i think the file formats haven't changed, it's just a case of adding normal maps maybe speculars as well, where poly counts maybe higher theres still no point of wasting them

The .ase files definitely work in Roboblitz's Editor (that's how I rendered that missile up there). My concern is more for the skeletal meshes for the vehicles.

Do we know if the vehicles are physics-based (like the old Karma vehicles (http://wiki.beyondunreal.com/wiki/KVehicle) such as the Bulldog) or if they are skeleton-based SVehicles like the original Onslaught set (ONSHoverBike = Manta, ONSChopperCraft = Raptor, etc.)?

Also, it's very true what you're saying regarding vehicle polycounts. I've been looking closely at the vehicle screenshots for weeks now, and the models don't seem to have all that many more polygons than the UT2004 versions. There's definitely more polys overall, but it's not like they did a jump from 5000 to 50,000. For instance, look at the Manta's cannons on Screenshot 8 on the UT3 home page. The barrels are essentially octagons/heptagons, but with smoothed edge normals and good normal / detail / specular maps they appear round and more complex. It's all about the illusion of complexity and efficiency of polygons.

[DGUnreal]

.ase is still the standard staticmesh import format.
UnrealEd also supports the usual .bmp .pcx .tga .psd texture files, and .psk or .dae skeletal meshes.

Vehicles are skeletal mesh.

I posted a partial list of player and vehicles triangle counts on another thread, you will have to search for it.

Regarding poly counts, you'll basically want to keep them at UT2004 level.
And except for Player/Vehicle models which can be 2048, most standard "world" textures should probably also be at UT2004 level of 512 or 1024, especially since there are usually more textures per shader material now. In most cases you can get excellent results with 128 through 512 textures if used properly in the shaders. If you are targetting consoles as well, use the smaller size textures. The only common exception to this is the skybox spherical texture which you'll want to use something like 2048x512.

Next-Gen doesn't mean that you get to make 50k poly objects and all 2048x2048 textures, that is an unnecessary waste for most assets.

[Hyncharas]

Since this is the first time we're dealing with "hovers" in the engine, how does this type differ from the gameplay compared to ground-based vehicles? Do they function more like aircraft or are they something else?

[kisk]

1) I'd imaging its coded so the anchor is attached to the board itself.

2) I'm hoping the new shading system will allow you to shade colors onto textures/skins.

3) That's how its always worked. Class inheritance ftw.

4) I always used the editor & a txt editor [Context]

5) Hope so :)

[WickedPenguin]

Since this is the first time we're dealing with "hovers" in the engine, how does this type differ from the gameplay compared to ground-based vehicles? Do they function more like aircraft or are they something else?

First time dealing with hovers? If you've played UT2004, you've already worked with "hovercraft". The Manta (ONSHoverbike) and Goliath (ONSHoverTank) were extensions of the ONSHovercraft class.

That Necris Viper bike seems to be just an offshoot of the Manta, although it seems like its "jump" feature is more gentle and sustained than the UT2004 Manta.

The vehicles that are really intriguing me as far as functionality are the walkers and the energy ball. Everything else we've seen before in its more basic form in UT2004. But the walkers are definitely going to open up a new genre in vehicle design. I'm really curious as to how they work. Do you build a regular skeleton and then just assign "feet" bones, length of steps, etc. in code, or is it all an illusion created entirely with animations (like many of the walker vehicles we saw based off of UT2004)?

Also, does anyone know if all of the maps are asymmetrical combat? By that I mean Human vs. Necris, each with their own set of different vehicles. Or will we have any Red vs. Blue maps with both sides having the same kinds of vehicles (like in UT2004)?

The reason I ask is, if you're going to design a vehicle, it kind of sucks if only one side can use it at a time. In UT2004, you could design one vehicle and just create red and blue skins for it. But in UT3, it would be kind of silly to have a human-looking vehicle with a slapped-on Necris skin and vice versa.

[stephen_wq]

In the meantime, here's a revised version of that missile I posted a couple of weeks ago. It's not perfect yet, but I've revised the texture and normal map.

Its going to be the new UT3 strangelove... right? right? :D:D:D

[A_FUDGECAKE]

keep working on that vehicle and missile thingy

[decoy26517]

Ok, I had some of the same answers and it was good to get some of the answers for them :)

However, one of the answers boggles me. I remember in the tech demos they released a long time ago they said that the scenes were made up of about 1,000,000 in game polys, but the source are was about 200,000,000 polys. I always thought they modders/artist would have to make 1 high res model and 1 low res model. Did I misunderstand something or did something change?

[DGUnreal]

You only need to make a hi-poly Detail model if you are planning on using it for mapping the detail Normal Map to the low-poly In-Game model version.
This is usually done for players and vehicles, but often regular world meshes can be normal mapped through other easier means.
You can create Normal Maps directly in Photoshop by painting them, or by creating unwrapped heightmap detailing models, etc.