[ X ]
TS/RA2 Voxel Support
Post new topic   Reply to topic Goto page 1, 2, 3, 4, 5  »
View previous topic :: View next topic  
Author Message
Sleipnir
Level: 150



Position: Administrator
Joined: 10 Apr 2002
Posts: 3854
Kel: 3347  [ Donate ]

Online Status: Offline
PostPosted: Sat Feb 23, 2013 10:40 am    Post subject: TS/RA2 Voxel Support Reply with quote

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:

http://www.sleipnirstuff.com/forum/files/units_821.png
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).

http://www.sleipnirstuff.com/forum/files/kirov_204.png
Kirov Reporting!

Code is available at pchote/OpenRA/voxels.
Back to top
View user's profile Find all posts by Sleipnir Send private message Send e-mail Visit poster's website MSN Messenger ICQ Number
BaronOfStuff
Level: 58



Position: Registered User
Joined: 22 May 2011
Posts: 356
Kel: 351  [ Donate ]

Online Status: Offline
PostPosted: Sat Feb 23, 2013 11:02 am  Reply with quote

That's pretty cool to see... They actually look a lot better in those screenshots than I thought they would.
Back to top
View user's profile Find all posts by BaronOfStuff Send private message ICQ Number
Harisson
Level: 74



Position: Registered User
Joined: 13 Jan 2008
Posts: 145
Kel: 126  [ Donate ]

Online Status: Offline
PostPosted: Sat Feb 23, 2013 1:47 pm  Reply with quote

SH*T !!!! THANKS !!! That's so cool and really helpful Smile
Back to top
View user's profile Find all posts by Harisson Send private message ICQ Number
Cmd. Matt
Developer
Level: 60



Position: Registered User
Joined: 01 May 2012
Posts: 771
Kel: 239  [ Donate ]

Online Status: Offline
PostPosted: Sat Feb 23, 2013 2:01 pm  Reply with quote

Awesome. Looks like OpenRA 2.0 is on it's way Wink
Back to top
View user's profile Find all posts by Cmd. Matt Send private message ICQ Number
katzsmile
Level: 57



Position: Registered User
Joined: 06 Sep 2010
Posts: 36
Kel: 37  [ Donate ]

Online Status: Offline
PostPosted: Sat Feb 23, 2013 4:31 pm  Reply with quote

One step closer to RA2 engine)
Back to top
View user's profile Find all posts by katzsmile Send private message Visit poster's website MSN Messenger ICQ Number
secret
Level: 75



Position: Registered User
Joined: 03 Aug 2007
Posts: 74
Kel: 58  [ Donate ]

Online Status: Offline
PostPosted: Sat Feb 23, 2013 5:37 pm  Reply with quote

Damn, that's pretty awesome.
Back to top
View user's profile Find all posts by secret Send private message ICQ Number
Sleipnir
Level: 150



Position: Administrator
Joined: 10 Apr 2002
Posts: 3854
Kel: 3347  [ Donate ]

Online Status: Offline
PostPosted: Sun Feb 24, 2013 9:14 am  Reply with quote

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




http://www.sleipnirstuff.com/forum/files/hmec_889.gif
Back to top
View user's profile Find all posts by Sleipnir Send private message Send e-mail Visit poster's website MSN Messenger ICQ Number
Cmd. Matt
Developer
Level: 60



Position: Registered User
Joined: 01 May 2012
Posts: 771
Kel: 239  [ Donate ]

Online Status: Offline
PostPosted: Sun Feb 24, 2013 11:58 am  Reply with quote

Can't compile your voxels branch Sad

Code:
CSC mods/ra/OpenRA.Mods.RA.dll
OpenRA.Mods.RA/Render/RenderVoxelTurreted.cs(53,18): error CS1729: The type `OpenRA.Traits.VoxelRenderable' does not contain a constructor that takes `8' arguments
/home/matthias/Projekte/OpenRA/OpenRA.Game.exe (Location of the symbol related to previous error)
OpenRA.Mods.RA/Render/RenderVoxelTurreted.cs(57,18): error CS1729: The type `OpenRA.Traits.VoxelRenderable' does not contain a constructor that takes `8' arguments
/home/matthias/Projekte/OpenRA/OpenRA.Game.exe (Location of the symbol related to previous error)
Compilation failed: 2 error(s), 0 warnings
Back to top
View user's profile Find all posts by Cmd. Matt Send private message ICQ Number
knivesron
Level: 52


Position: Registered User
Joined: 10 Aug 2011
Posts: 93
Kel: 110  [ Donate ]

Online Status: Offline
PostPosted: Sun Feb 24, 2013 8:41 pm  Reply with quote

omg
this is looking great. i cant wait to play ts and ra2 in openra. itll be boss as.
Back to top
View user's profile Find all posts by knivesron Send private message ICQ Number
Sleipnir
Level: 150



Position: Administrator
Joined: 10 Apr 2002
Posts: 3854
Kel: 3347  [ Donate ]

Online Status: Offline
PostPosted: Sun Feb 24, 2013 8:50 pm  Reply with quote

Cmd. Matt wrote (View Post):
Can't compile your voxels branch Sad

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.
Back to top
View user's profile Find all posts by Sleipnir Send private message Send e-mail Visit poster's website MSN Messenger ICQ Number
Cmd. Matt
Developer
Level: 60



Position: Registered User
Joined: 01 May 2012
Posts: 771
Kel: 239  [ Donate ]

Online Status: Offline
PostPosted: Mon Feb 25, 2013 8:23 am  Reply with quote

Sleipnir wrote (View Post):
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?
Back to top
View user's profile Find all posts by Cmd. Matt Send private message ICQ Number
Sleipnir
Level: 150



Position: Administrator
Joined: 10 Apr 2002
Posts: 3854
Kel: 3347  [ Donate ]

Online Status: Offline
PostPosted: Mon Feb 25, 2013 9:46 am  Reply with quote

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.
Back to top
View user's profile Find all posts by Sleipnir Send private message Send e-mail Visit poster's website MSN Messenger ICQ Number
Cmd. Matt
Developer
Level: 60



Position: Registered User
Joined: 01 May 2012
Posts: 771
Kel: 239  [ Donate ]

Online Status: Offline
PostPosted: Mon Feb 25, 2013 11:27 am  Reply with quote

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.
Back to top
View user's profile Find all posts by Cmd. Matt Send private message ICQ Number
chrisf
Level: 61


Position: Moderator
Joined: 06 Sep 2010
Posts: 246
Kel: 259  [ Donate ]

Online Status: Offline
PostPosted: Mon Feb 25, 2013 8:05 pm  Reply with quote

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.
Back to top
View user's profile Find all posts by chrisf Send private message Send e-mail ICQ Number
Sleipnir
Level: 150



Position: Administrator
Joined: 10 Apr 2002
Posts: 3854
Kel: 3347  [ Donate ]

Online Status: Offline
PostPosted: Mon Feb 25, 2013 9:31 pm  Reply with quote

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 Sad

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.
Back to top
View user's profile Find all posts by Sleipnir Send private message Send e-mail Visit poster's website MSN Messenger ICQ Number
Display posts from previous:   
Post new topic   Reply to topic Goto page 1, 2, 3, 4, 5  »