The Art of Rubicon 1.1
Posted: Wed Jan 29, 2014 5:28 pm
http://community.eveonline.com/news/dev ... bicon-1.1/
Greetings capsuleers, CCP BlueScreen here reporting for Team TriLambda (EVE’s ‘art’ team). o7
It’s been a while since we talked. I hear tales of unrest-- the pod pilots of New Eden are awaiting news from the north. Fear not, the ravens are inbound.
We at Team TriLambda, the biggest and longest standing development team assigned to EVE Online, have been hard at work preparing an array of updates and additions for the Rubicon 1.1 release.
Today I will be covering TriLambda’s general development work for Rubicon 1.1 and then focus on a more detailed account of the capital wreck creation.
Before we get to that though, it’s important to note that this dev blog was written before the Bloodbath of B-R5RB. You can read more about that incredible player event and our plans for an in-game monument called “Titanomachy” to commemorate it in this new dev blog by CCP Dolan. The happy coincidence of the capital wreck work described in this blog is not lost on us.
Rubicon 1.1 and TriLambda
CCP Huskarl and CCP BunnyVirus have been hard at work completing the Sister of EVE (SoE) faction lineup. On January 28th we delivered, to a marketplace near you, the Nestor SoE battleship class hull:
You can read about the Nestor stats here.
Continuing our efforts on the long standing “V3” project spearheaded by CCP Salvo, we updated again textures, applying our newest shaders and adding new effects to existing content. This time around we delivered 44 fully renovated and V3’ed stations to New Eden. Here are a few of them.
Also, our ship redesign efforts continue. This time around, via our in house chess boxing champion CCP LeftRook and German exile CCP Phor, TriLambda delivered the reimagined Crucifier.
CCP Caiman, CCP Gorgen, CCP LuxusLulli, CCP Angler and CCP Hansuman (a group of CCP’s finest) combined to add to Rubicon’s mobile deployable structure collection.
In Rubicon 1.1 we added three new units for the citizens of New Eden to enjoy.
The ‘Encounter Surveillance System’, ‘Mobile Micro Jump Drive’ and the ‘Mobile Scan Inhibitor’. In addition to this we will be adding two skin variation of the already deployed ‘Siphon Unit’, that is the ‘Small Mobile ‘Hybrid’ Siphon’ and the ‘Small Mobile ‘Rote’ Siphon’.
For more info on all of these new mobile units and their functions please refer to the Dev Blogs:
http://community.eveonline.com/news/dev ... r-friends/
http://community.eveonline.com/news/dev ... tructures/
CCP Mannapi delivered, for your enjoyment, a vastly improved icon rendering technique which isn’t dependent on user hardware.
We have also implemented some small render quality improvements for the EVE client. This includes optimizations and dynamic adjustment for the near-far camera clipping plane and shadow calculations.
And guess what. Remember those space clouds we all hold so dear to our hearts? Well now you can now turn them off if they give your computer/graphics cars any trouble. The ‘effect’ setting will now toggle particle clouds on/off. A session change is required for this to take effect.
That was a quick run through of some of the things we have been up to over the holidays. Now let’s turn to wrecking capital ships.
How to Wreck a Spaceship 101
Today's story is one about destruction and demise. A manual of sorts. We hope you will enjoy the read and proceed to have as much fun “spawning” wrecks on the battlefield as we had creating them.
We at TriLambda have been wanting to update the capital wrecks for a while now.
While not technically part of the V3 process (the wrecks currently in client are already V3'ed), sometimes during this process you simply stumble onto things, where a simple texture tweak or shader change won’t do the trick. Massive ship wrecks were one of those things.
So why the update?
Current capital wrecks are little more than darker versions of the original ships. At close range you may or may not notice some holes punched through the hull which reveal a seemingly paper-thin shell of a completely empty ship volume.
From a visual and artistic standpoint, these assets just don't live up to the standards of what we like to label 'renovated content'. The wrecks were dull at best and offered no immersion.
Couple this with the challenge it could sometimes be just to tell a wreck apart from its fully alive and operational counterpart, and we finally had to act.
A wreck of old, not always so easily identifiable as such.
What then could a wreck look like?
We wanted to create visually convincing and distinct wrecks but had to figure out where best to start.
Could we break the ship geometry apart, to give it that distinct silhouette of wreckage torn apart? If not, could we utilize some render effects to simulate this effect?
If we could actually break the meshes apart in a feasible manner, how would we represent the interiors of the ships? We had never done anything like that before.
The how and the who of it all?
Now how does one go about implementing an update like this, and what amount of resources can you justify throwing at a renovation project like this.
Now, I’m not the guy who revamps POS gameplay or fixes lag. This project sits on my desktop because I am the guy who adds polygons, effects and particle systems to EVE online. Once my work is done, CCP ManKiller comes by, looks at my FPS, and threatens to throw me out the window*.
CCP ManKiller, you don’t want this guy looking over your shoulder.
With any feature and/or project in EVE we make an assessment of “end user value” vs. “feature development cost”.
It was clear from the outset, that simply assigning a bunch of artists to create completely new wreck assets was not a practical solution. Even manually breaking apart the original ships (if that was even possible) and creating new wrecks on a ‘one by one basis’ would involve artist resources way beyond the value of the project.
We needed a better understanding of what exactly we COULD do and if any of this was actually feasible.
* CCP Mankiller did write the shaders for these wrecks, and by and large facilitated the integration of wrecks into the client. So if you see him lurking about the streets at night, do keep your distance, but yell out a big salute to this all in all great mensch.
Research and Development
R&D would be the next step. Enter senior technical artist CCP Ph00ze.
CCP Ph00ze went into isolation, literally, and started digging into all the options. Were the original ideas practical? If they weren’t, could we replace them with another more feasible approach?
A few weeks went by spent trying and testing, running hair-pulling Maya Boolean experiments, and iterative tools building.
At a point it became clear that with enough stubbornness, backup plans and fixes to the basic Maya Boolean system, we could actually break our original ships apart.
Once Booleans fell into place and a decent art-directable method to use them was found, everything started falling into place. From there we could try out interior technology, automate breaking surface detail, extrude edges and so on.
What we had created was a method for procedurally creating wrecked versions of original assets-- a method that, as it where, involved very little repetitive manual content work, and that, when in place, could be used over and over again for future dividends.
At this point the tools were promising enough that a 3D Artist (yours truly), was assigned to test them. I started creating the first “real” wreck-- something that looked good enough to use in the game.
My first order of business was to catch up with Ph00ze and wrap my head around the tools, their functionality and the possibilities they would open up. Prototyping on the actual capital ship assets could begin.
Prototyping
During the initial prototype phase processes and tools are in constant development and in a back and forth iteration between the technical artist and the 3D artist.
While the 3D artist is initially trying out the tools and reporting back on functionality and defects, the technical artist continues to develop new ways of improving and adding to the process of capital wreck creation.
The tools quickly become streamlined into a very efficient process with a lot of automated steps. A lot of experimental tricks a tried during this phase.
Look mom, I made a flow chart!
Not many assets get created at this point as time is mainly invested in creating one visual target that acts as a proof of concept.
This approach has both the benefit of fast and focused iteration and bug fixing, while also avoiding the risk of creating flawed content in bulk that would then have to be retroactively fixed or remade.
After this initial phase we reached a point in development where we basically had our first capital wreck done and the processes and tools were in place. During the process some tools were scrapped, others were added and pretty much all of them were tweaked and polished.
At this point we gathered all of our tools into one ‘step by step’ integrated Maya UI, and we marched forward into production.
The wreck tools, ready to have a go at the Fenrir.
Production
First order of business was to create some ‘Cutters’-- basically a set of shattered 3D volumes that determine how and where the ship is broken and fragmented.
These volumes are reusable between assets and can be rotated, scaled and tweaked to fit any ship and create a variety of ship breakups.
In addition to breaking the ships apart, this complex Boolean process would also cap all mesh holes created by the breakup by applying correct UV’s as well as the correct ‘damaged Interior’ materials and textures onto these surfaces.
Once the ship has been broken into pieces, you can use any physics simulator to scatter the wreckage and debris as you please.
Shattering a ship with advanced Booleans using the pre-fabricated ‘Cutter’ geometry.
Now the Fenrir has been broken quite severely but the breaking points still look very clean and straight. It doesn’t exactly look like anything ‘sploded around here now does it?
To fix that we have a couple of tools at our disposal. Firstly we add some ‘Edge debris’. This basically means extruding the armor plating around the cut along any axis we choose at any length we choose.
In this case we will extrude along the Z-axis of the ship.
When we do the extrusion the tool will automatically UV the extruded geometry for us and apply the correct debris texture. In addition the tool automatically paints all edge vertices black along with the base vertices of the extruded geometry. This fades in a damage texture on the final wreck and ensures a smooth transition between ship hull and extruded armor plating.
Adding extruded debris geometry and adding transition using vertex coloring.
Another option we have to add detail to the interior cut sections is to spawn premade debris geometry on these. We can spawn any number of different debris pieces at any size, angle and rotation.
This serves especially well to add a more realistic mangled look to smaller debris fragment, that doesn’t warrant any big armor plating extrusions.
Debris beams spawned on small fragment.
At this point we have the base wreck ready. Through the wreck tool we can now auto generate an ambient occlusion UVset and bake our AO map.
Basically, because the primary UVset of the capital ships are using tiled UVs, meaning that not all surface areas of the ships has its own unique texturespace, for us to be able to give every area of the ships its own correct light occlusion, we add a secondary unique UVset which is then used to bake out and apply an ambient occlusion map.
We can now also paint some additional vertex color to add additional damage and dirt to the hull exactly where we want it.
Finished base wreck mesh, ready for game engine export.
There a still something missing here though. Check out those big empty spaces between all the major fragments. Seems we need something to tie this mass together. Time for another feature request I guess
While I had been wrecking my ship my feature needs had been duly anticipated by CCP Ph00ze, who had already done some prototyping of exactly what I was looking for. Enter small debris and dust cloud particle systems.
All I had to do was find the right values for particle amount, size, colors etc. and the tool would do the rest.
Basically the debris tool places two particle emitters at the breaking points of each fragment and then reassembles the ship to its original position.
The system then, over a 100 frame timeline duration, animates all the fragments back to their ‘wreck position’. While running this animation the emitters leave a trail behind the fragments of smoke and small debris pieces (hence two emitters per Fragment).
The amount of smoke and debris each fragment emits is X multiplied by the total surface area of the fragments ‘interior’ parts.
The smoke is colored based on how close it is to its parent fragment, so that smoke that lies right up against the fragment has an slight orange tint from the fire and molten metal that surrounds it.
Likewise, small particle debris that lies close up against its parent fragment has a greater chance of having glowing surfaces than debris further away.
Particle clouds did cause us some technical headaches.
Upon exporting our first wreck with particle clouds and debris, it became clear we were going to have sorting problems with two (or more) overlapping particle systems.
The sorting problems initially put us off the particle systems for a bit, but we realized that this issue was going to have to be solved in any case. Particle systems or no, the ship explosion itself would break if we didn’t fix this issue. It was time to look up CCP ManKiller again.
After some looking into the issue, he came through with flying colors, fixing our issue by having the debris particles write to the depth buffer. We could have our clouds.
Finished base wreck mesh including particle clouds.
Now were ready to export our wreck and take a look in our game engine tool (AKA "Jessica").
This is a far cry from the all-but-forgotten wrecks of pre-Rubicon. A keen eye will observe some details that have not yet been mentioned in our wreck creation process: damage decals. More specifically, cube maps projected onto the hull, with surrounding damage and dirt to give the illusion if hull breaches with interior damage.
And so, alas, we reach the end of the Fenrir. With now one capital down and 26 to go, our time spent on tools building and prototyping really paid off.
Again, with but one lonely 3D artist and his technical artist buddy, we cut our way through the rest of the 27 capitals in time to deliver them all to you with Rubicon 1.1.
We hope you enjoyed this little insight into some of our asset creation processes, and again, we hope you will enjoy littering the battlefield with these as much as we did creating them
Oh yes, almost forgot, let’s look at some more wrecks now that we are here.
It’s not often people see wrecks of this size in game, so we’re extra excited to see the Titanomachy site going in game to have a permanent (if not super dangerous) place to see these in space.
And with that, I am CCP BlueScreen, and this is Team Trilambda signing off. We wish you safe travels.
No seriously, fly safe and stay immortal o7
So now that I have this tool, what to wreck next …?
Greetings capsuleers, CCP BlueScreen here reporting for Team TriLambda (EVE’s ‘art’ team). o7
It’s been a while since we talked. I hear tales of unrest-- the pod pilots of New Eden are awaiting news from the north. Fear not, the ravens are inbound.
We at Team TriLambda, the biggest and longest standing development team assigned to EVE Online, have been hard at work preparing an array of updates and additions for the Rubicon 1.1 release.
Today I will be covering TriLambda’s general development work for Rubicon 1.1 and then focus on a more detailed account of the capital wreck creation.
Before we get to that though, it’s important to note that this dev blog was written before the Bloodbath of B-R5RB. You can read more about that incredible player event and our plans for an in-game monument called “Titanomachy” to commemorate it in this new dev blog by CCP Dolan. The happy coincidence of the capital wreck work described in this blog is not lost on us.
Rubicon 1.1 and TriLambda
CCP Huskarl and CCP BunnyVirus have been hard at work completing the Sister of EVE (SoE) faction lineup. On January 28th we delivered, to a marketplace near you, the Nestor SoE battleship class hull:
You can read about the Nestor stats here.
Continuing our efforts on the long standing “V3” project spearheaded by CCP Salvo, we updated again textures, applying our newest shaders and adding new effects to existing content. This time around we delivered 44 fully renovated and V3’ed stations to New Eden. Here are a few of them.
Also, our ship redesign efforts continue. This time around, via our in house chess boxing champion CCP LeftRook and German exile CCP Phor, TriLambda delivered the reimagined Crucifier.
CCP Caiman, CCP Gorgen, CCP LuxusLulli, CCP Angler and CCP Hansuman (a group of CCP’s finest) combined to add to Rubicon’s mobile deployable structure collection.
In Rubicon 1.1 we added three new units for the citizens of New Eden to enjoy.
The ‘Encounter Surveillance System’, ‘Mobile Micro Jump Drive’ and the ‘Mobile Scan Inhibitor’. In addition to this we will be adding two skin variation of the already deployed ‘Siphon Unit’, that is the ‘Small Mobile ‘Hybrid’ Siphon’ and the ‘Small Mobile ‘Rote’ Siphon’.
For more info on all of these new mobile units and their functions please refer to the Dev Blogs:
http://community.eveonline.com/news/dev ... r-friends/
http://community.eveonline.com/news/dev ... tructures/
CCP Mannapi delivered, for your enjoyment, a vastly improved icon rendering technique which isn’t dependent on user hardware.
We have also implemented some small render quality improvements for the EVE client. This includes optimizations and dynamic adjustment for the near-far camera clipping plane and shadow calculations.
And guess what. Remember those space clouds we all hold so dear to our hearts? Well now you can now turn them off if they give your computer/graphics cars any trouble. The ‘effect’ setting will now toggle particle clouds on/off. A session change is required for this to take effect.
That was a quick run through of some of the things we have been up to over the holidays. Now let’s turn to wrecking capital ships.
How to Wreck a Spaceship 101
Today's story is one about destruction and demise. A manual of sorts. We hope you will enjoy the read and proceed to have as much fun “spawning” wrecks on the battlefield as we had creating them.
We at TriLambda have been wanting to update the capital wrecks for a while now.
While not technically part of the V3 process (the wrecks currently in client are already V3'ed), sometimes during this process you simply stumble onto things, where a simple texture tweak or shader change won’t do the trick. Massive ship wrecks were one of those things.
So why the update?
Current capital wrecks are little more than darker versions of the original ships. At close range you may or may not notice some holes punched through the hull which reveal a seemingly paper-thin shell of a completely empty ship volume.
From a visual and artistic standpoint, these assets just don't live up to the standards of what we like to label 'renovated content'. The wrecks were dull at best and offered no immersion.
Couple this with the challenge it could sometimes be just to tell a wreck apart from its fully alive and operational counterpart, and we finally had to act.
A wreck of old, not always so easily identifiable as such.
What then could a wreck look like?
We wanted to create visually convincing and distinct wrecks but had to figure out where best to start.
Could we break the ship geometry apart, to give it that distinct silhouette of wreckage torn apart? If not, could we utilize some render effects to simulate this effect?
If we could actually break the meshes apart in a feasible manner, how would we represent the interiors of the ships? We had never done anything like that before.
The how and the who of it all?
Now how does one go about implementing an update like this, and what amount of resources can you justify throwing at a renovation project like this.
Now, I’m not the guy who revamps POS gameplay or fixes lag. This project sits on my desktop because I am the guy who adds polygons, effects and particle systems to EVE online. Once my work is done, CCP ManKiller comes by, looks at my FPS, and threatens to throw me out the window*.
CCP ManKiller, you don’t want this guy looking over your shoulder.
With any feature and/or project in EVE we make an assessment of “end user value” vs. “feature development cost”.
It was clear from the outset, that simply assigning a bunch of artists to create completely new wreck assets was not a practical solution. Even manually breaking apart the original ships (if that was even possible) and creating new wrecks on a ‘one by one basis’ would involve artist resources way beyond the value of the project.
We needed a better understanding of what exactly we COULD do and if any of this was actually feasible.
* CCP Mankiller did write the shaders for these wrecks, and by and large facilitated the integration of wrecks into the client. So if you see him lurking about the streets at night, do keep your distance, but yell out a big salute to this all in all great mensch.
Research and Development
R&D would be the next step. Enter senior technical artist CCP Ph00ze.
CCP Ph00ze went into isolation, literally, and started digging into all the options. Were the original ideas practical? If they weren’t, could we replace them with another more feasible approach?
A few weeks went by spent trying and testing, running hair-pulling Maya Boolean experiments, and iterative tools building.
At a point it became clear that with enough stubbornness, backup plans and fixes to the basic Maya Boolean system, we could actually break our original ships apart.
Once Booleans fell into place and a decent art-directable method to use them was found, everything started falling into place. From there we could try out interior technology, automate breaking surface detail, extrude edges and so on.
What we had created was a method for procedurally creating wrecked versions of original assets-- a method that, as it where, involved very little repetitive manual content work, and that, when in place, could be used over and over again for future dividends.
At this point the tools were promising enough that a 3D Artist (yours truly), was assigned to test them. I started creating the first “real” wreck-- something that looked good enough to use in the game.
My first order of business was to catch up with Ph00ze and wrap my head around the tools, their functionality and the possibilities they would open up. Prototyping on the actual capital ship assets could begin.
Prototyping
During the initial prototype phase processes and tools are in constant development and in a back and forth iteration between the technical artist and the 3D artist.
While the 3D artist is initially trying out the tools and reporting back on functionality and defects, the technical artist continues to develop new ways of improving and adding to the process of capital wreck creation.
The tools quickly become streamlined into a very efficient process with a lot of automated steps. A lot of experimental tricks a tried during this phase.
Look mom, I made a flow chart!
Not many assets get created at this point as time is mainly invested in creating one visual target that acts as a proof of concept.
This approach has both the benefit of fast and focused iteration and bug fixing, while also avoiding the risk of creating flawed content in bulk that would then have to be retroactively fixed or remade.
After this initial phase we reached a point in development where we basically had our first capital wreck done and the processes and tools were in place. During the process some tools were scrapped, others were added and pretty much all of them were tweaked and polished.
At this point we gathered all of our tools into one ‘step by step’ integrated Maya UI, and we marched forward into production.
The wreck tools, ready to have a go at the Fenrir.
Production
First order of business was to create some ‘Cutters’-- basically a set of shattered 3D volumes that determine how and where the ship is broken and fragmented.
These volumes are reusable between assets and can be rotated, scaled and tweaked to fit any ship and create a variety of ship breakups.
In addition to breaking the ships apart, this complex Boolean process would also cap all mesh holes created by the breakup by applying correct UV’s as well as the correct ‘damaged Interior’ materials and textures onto these surfaces.
Once the ship has been broken into pieces, you can use any physics simulator to scatter the wreckage and debris as you please.
Shattering a ship with advanced Booleans using the pre-fabricated ‘Cutter’ geometry.
Now the Fenrir has been broken quite severely but the breaking points still look very clean and straight. It doesn’t exactly look like anything ‘sploded around here now does it?
To fix that we have a couple of tools at our disposal. Firstly we add some ‘Edge debris’. This basically means extruding the armor plating around the cut along any axis we choose at any length we choose.
In this case we will extrude along the Z-axis of the ship.
When we do the extrusion the tool will automatically UV the extruded geometry for us and apply the correct debris texture. In addition the tool automatically paints all edge vertices black along with the base vertices of the extruded geometry. This fades in a damage texture on the final wreck and ensures a smooth transition between ship hull and extruded armor plating.
Adding extruded debris geometry and adding transition using vertex coloring.
Another option we have to add detail to the interior cut sections is to spawn premade debris geometry on these. We can spawn any number of different debris pieces at any size, angle and rotation.
This serves especially well to add a more realistic mangled look to smaller debris fragment, that doesn’t warrant any big armor plating extrusions.
Debris beams spawned on small fragment.
At this point we have the base wreck ready. Through the wreck tool we can now auto generate an ambient occlusion UVset and bake our AO map.
Basically, because the primary UVset of the capital ships are using tiled UVs, meaning that not all surface areas of the ships has its own unique texturespace, for us to be able to give every area of the ships its own correct light occlusion, we add a secondary unique UVset which is then used to bake out and apply an ambient occlusion map.
We can now also paint some additional vertex color to add additional damage and dirt to the hull exactly where we want it.
Finished base wreck mesh, ready for game engine export.
There a still something missing here though. Check out those big empty spaces between all the major fragments. Seems we need something to tie this mass together. Time for another feature request I guess
While I had been wrecking my ship my feature needs had been duly anticipated by CCP Ph00ze, who had already done some prototyping of exactly what I was looking for. Enter small debris and dust cloud particle systems.
All I had to do was find the right values for particle amount, size, colors etc. and the tool would do the rest.
Basically the debris tool places two particle emitters at the breaking points of each fragment and then reassembles the ship to its original position.
The system then, over a 100 frame timeline duration, animates all the fragments back to their ‘wreck position’. While running this animation the emitters leave a trail behind the fragments of smoke and small debris pieces (hence two emitters per Fragment).
The amount of smoke and debris each fragment emits is X multiplied by the total surface area of the fragments ‘interior’ parts.
The smoke is colored based on how close it is to its parent fragment, so that smoke that lies right up against the fragment has an slight orange tint from the fire and molten metal that surrounds it.
Likewise, small particle debris that lies close up against its parent fragment has a greater chance of having glowing surfaces than debris further away.
Particle clouds did cause us some technical headaches.
Upon exporting our first wreck with particle clouds and debris, it became clear we were going to have sorting problems with two (or more) overlapping particle systems.
The sorting problems initially put us off the particle systems for a bit, but we realized that this issue was going to have to be solved in any case. Particle systems or no, the ship explosion itself would break if we didn’t fix this issue. It was time to look up CCP ManKiller again.
After some looking into the issue, he came through with flying colors, fixing our issue by having the debris particles write to the depth buffer. We could have our clouds.
Finished base wreck mesh including particle clouds.
Now were ready to export our wreck and take a look in our game engine tool (AKA "Jessica").
This is a far cry from the all-but-forgotten wrecks of pre-Rubicon. A keen eye will observe some details that have not yet been mentioned in our wreck creation process: damage decals. More specifically, cube maps projected onto the hull, with surrounding damage and dirt to give the illusion if hull breaches with interior damage.
And so, alas, we reach the end of the Fenrir. With now one capital down and 26 to go, our time spent on tools building and prototyping really paid off.
Again, with but one lonely 3D artist and his technical artist buddy, we cut our way through the rest of the 27 capitals in time to deliver them all to you with Rubicon 1.1.
We hope you enjoyed this little insight into some of our asset creation processes, and again, we hope you will enjoy littering the battlefield with these as much as we did creating them
Oh yes, almost forgot, let’s look at some more wrecks now that we are here.
It’s not often people see wrecks of this size in game, so we’re extra excited to see the Titanomachy site going in game to have a permanent (if not super dangerous) place to see these in space.
And with that, I am CCP BlueScreen, and this is Team Trilambda signing off. We wish you safe travels.
No seriously, fly safe and stay immortal o7
So now that I have this tool, what to wreck next …?