TS/RA2 Voxel Support

Post by **Sleipnir** » Sat Feb 23, 2013 10:40 am

It's been a while since I touched anything with OpenRA, so I thought it'd be fun to hack on something. I decided to add support for TS/RA2 voxels.

The underlying framework is done, but there's still a bunch of polish and integration that would need to be done to make it shippable.
The two most important things left to solve are adding appropriate Z coordinates to the 2D code to allow proper overlapping of units (right now, voxels are rendered above the terrain, but behind everything else), and culling interior faces to improve performance (Each airship in the screenshot below is 430k triangles right now).

A couple of demo screenshots:

Tiberian Sun ships a bunch of C&C/RA1 units in voxel form, but some of them are broken (e.g. MRLS turret, and a Jeep voxel with an inconsistent hva).

Kirov Reporting!

Code is available at pchote/OpenRA/voxels.

BaronOfStuff · Post by **BaronOfStuff** » Sat Feb 23, 2013 11:02 am

That's pretty cool to see... They actually look a lot better in those screenshots than I thought they would.

Harisson · Post by **Harisson** » Sat Feb 23, 2013 1:47 pm

SH*T !!!! THANKS !!! That's so cool and really helpful

Matt · Post by **Matt** » Sat Feb 23, 2013 2:01 pm

Awesome. Looks like OpenRA 2.0 is on it's way

katzsmile · Post by **katzsmile** » Sat Feb 23, 2013 4:31 pm

One step closer to RA2 engine)

secret · Post by **secret** » Sat Feb 23, 2013 5:37 pm

Damn, that's pretty awesome.

Post by **Sleipnir** » Sun Feb 24, 2013 9:14 am

If anyone wants to try it, you can extract this package onto a playtest-20130128 install, and then select the voxel test mod from the mod selector.

The mod replaces all the vehicles/aircraft in C&C with units from TS (proper units, not the unused artwork I posted earlier).
EA freewared TS a few years ago, so distributing the art is no worse than C&C/RA1.

Known bugs/limitations:

Only works with the Gl renderer (I'm not familiar with the Cg shader language)
Performance is terrible once you have more than a couple of units onscreen (still need to cull internal faces)
Z-sorting vs sprites still doesn't work
Harvesting currently doesn't work - some muppet (possibly me) tied the harvesting logic to the sprite rendering code.
There's a bug in the lighting calculations, so units look a bit strange from some angles
Graphic overlays (smoke, muzzleflash) currently don't work

Matt · Post by **Matt** » Sun Feb 24, 2013 11:58 am

Can't compile your voxels branch

Code: Select all

CSC mods/ra/OpenRA.Mods.RA.dll
OpenRA.Mods.RA/Render/RenderVoxelTurreted.cs&#40;53,18&#41;&#58; error CS1729&#58; The type `OpenRA.Traits.VoxelRenderable' does not contain a constructor that takes `8' arguments
/home/matthias/Projekte/OpenRA/OpenRA.Game.exe &#40;Location of the symbol related to previous error&#41;
OpenRA.Mods.RA/Render/RenderVoxelTurreted.cs&#40;57,18&#41;&#58; error CS1729&#58; The type `OpenRA.Traits.VoxelRenderable' does not contain a constructor that takes `8' arguments
/home/matthias/Projekte/OpenRA/OpenRA.Game.exe &#40;Location of the symbol related to previous error&#41;
Compilation failed&#58; 2 error&#40;s&#41;, 0 warnings

knivesron · Post by **knivesron** » Sun Feb 24, 2013 8:41 pm

omg
this is looking great. i cant wait to play ts and ra2 in openra. itll be boss as.

Post by **Sleipnir** » Sun Feb 24, 2013 8:50 pm

Cmd. Matt wrote: ↑Can't compile your voxels branch

Looks like I forgot to commit the changes to that file. Fixed.

If you're launching from the commandline, you must use Game.Mods=voxeltest,cnc for it to run.

I have a few thoughts on how (optional) isometry can be added without throwing out half the engine, but its would require a bunch more refactoring. As a bonus, it would also fix the desync problems you appear to have been dealing with lately.

Matt · Post by **Matt** » Mon Feb 25, 2013 8:23 am

Sleipnir wrote: ↑I have a few thoughts on how (optional) isometry can be added without throwing out half the engine, but its would require a bunch more refactoring. As a bonus, it would also fix the desync problems you appear to have been dealing with lately.

Where do you suspect the bug? Somewhere deep in the coordinate system?

Post by **Sleipnir** » Mon Feb 25, 2013 9:46 am

The bug *is* the coordinate system. You can argue symptoms until the cows come home, but the real problem is that the positioning code is a mess.
The engine has evolved a bunch of different coordinates, with (to the casual contributor, where the danger is) arbitrary conversions between them - particularly when going to and from floats (which should only be used in the renderer).

My solution would be to transition the engine (over a series of patches, a single monolithic change is just asking for trouble) to exactly two sets of coordinates.
Everything except pathfinding and building placement (which are naturally cell-based) would use "world coordinates", defined by (x,y,z) 32-bit signed integers, with 1024 units per cell, and a similarly defined (roll,pitch,yaw) rotation. The simulation parts of the engine would have no concept of pixels or floating point calculations.
The renderer would convert world coordinates to screen coordinates during the render phase, making it trivial to switch between rendering models (isometric / whatever you call the current system) and would allow some interesting possibilities like (assuming artwork support) rotating the camera in 90 degree increments to get a different perspective of the map.

Matt · Post by **Matt** » Mon Feb 25, 2013 11:27 am

I will buy you a beer of you finally fix this and add a nice rotation feature on the way. It will look weird like in the Caesar/Zeus games where they only drew one side of the buildings. Anyway I agree the positioning system is extremely confusing and calculating hits within machine epsilon smells like problems. The changes to help avoid those problems ironically might be responsible for the horrible and hard to track desync bugs.

Post by **chrisf** » Mon Feb 25, 2013 8:05 pm

Looks awesome.

Is it worth baking the views of the voxel units down into sprites so they're not quite so expensive to draw? (probably via render-to-texture) Thousands of triangles per unit isnt going to fly on low-end hardware.

I agree that the various coordinate systems are a mess. Your proposal sounds like a sensible way to go.

Post by **Sleipnir** » Mon Feb 25, 2013 9:31 pm

I want to support arbitrary rotations (for things like death-spirals for aircraft), so RTT would require a prohibitive amount of texture space. Even the combination of facings plus pitch (for RA2/TS sloping tiles) over a reasonable number of faces would be too much.
One possibility would be to cache the common facings in a texture, with a fallback to generate a new frame on the fly if it doesn't exist. This would add a pile of complexity though

A different approach would be to group adjacent co-planar quads into larger polygons with color/normal indices stored in a mapped texture. This would help a lot for boxy units, but would be useless for things with a lot of steps (i.e. most units)... it's probably not worth the effort.

A third approach would be to render the unit as <x>*<y>*<z> planes mapped with the different slices through the unit. This might actually be feasible.

I'm tempted to take due care with optimizing things (e.g removing interior faces and enabling backface culling), and then just tell people with super-low end hardware that still can't handle it to go play a Facebook game.