Forums » Suggestions
How complex can your ship models be?
Can you do normal mapping?
How many poly's per ship can your current engine push?
How many UV map layers can you have?
Do you bake your textures?
etc..
I'm a 3D artist in my spare time and so far I am enjoying VO.. I figure maybe we could work something out =)
I use Modo and Lightwave and have created quite a few 3D models in my time.. It would amuse me to create ships for VO..
So with that.. would you be open to replacing a ship model or models with a new version? Same basic design maybe but just newer look?
Can you do normal mapping?
How many poly's per ship can your current engine push?
How many UV map layers can you have?
Do you bake your textures?
etc..
I'm a 3D artist in my spare time and so far I am enjoying VO.. I figure maybe we could work something out =)
I use Modo and Lightwave and have created quite a few 3D models in my time.. It would amuse me to create ships for VO..
So with that.. would you be open to replacing a ship model or models with a new version? Same basic design maybe but just newer look?
sigh...new ships. Yeah, that'd be really cool...get used to the idea of choking on variants of existing ships. If you pop over to community projects you'll find a few treads over flowing with great designs.
The focus of current development is on adding features that enhance game play. While improving the appearance of the ships would certainly be an enhancement, there's a lot of things we've needed around here for a long time that are being added in now.
While your artistry may be flawless, the real time-sink for ships in VO is modeling collision meshes and the other mechanical details. Eventually the developers may find the time to build better tools for this, but right now all their efforts are going into some sorely-needed feature sets and upgrades. Training somebody new to prepare VO-ready models would be prohibitively time consuming. For the moment the developers are open to tweaking the performance characteristics of existing models to create variants. Rest assured they'll put the call out if they are ready for help modeling.
You may choose to "choke" on these, but my perspective is that the developers are doing their best to do the work that is needed while still accommodating less urgent user requests as best they can.
While your artistry may be flawless, the real time-sink for ships in VO is modeling collision meshes and the other mechanical details. Eventually the developers may find the time to build better tools for this, but right now all their efforts are going into some sorely-needed feature sets and upgrades. Training somebody new to prepare VO-ready models would be prohibitively time consuming. For the moment the developers are open to tweaking the performance characteristics of existing models to create variants. Rest assured they'll put the call out if they are ready for help modeling.
You may choose to "choke" on these, but my perspective is that the developers are doing their best to do the work that is needed while still accommodating less urgent user requests as best they can.
money=production+quality, quality production+visually appealing graphics=more players=more money=more devs=more time=equals more players=more money
see how that works?
by the way Whistler...can you actually breathe methane? or do you have to come up for air?
see how that works?
by the way Whistler...can you actually breathe methane? or do you have to come up for air?
@Whistler: I don't for a second pretend to know all the technological elements of model creation for this game, that's why I started my thread by asking =) .. I'm just wondering if they would be open to the idea..
As to Ryans point, I would have to assume that better visuals would only help the game -- having said that I have no real clue on the impact to the game though..
As to Ryans point, I would have to assume that better visuals would only help the game -- having said that I have no real clue on the impact to the game though..
Palamedes: I'm just regurgitating what the devs have said in reply to previous offers for model creation. Currently they're not open to it for the reasons I cited, but maybe they will be some day.
There's no doubt that better visuals would help the game - it's just that the development focus is on other elements right now. There's only 4 developers, so that focus is usually fairly narrow.
Here's a thread I was looking for earlier that may have made things clearer: http://www.vendetta-online.com/x/msgboard/1/16424#207671
There's no doubt that better visuals would help the game - it's just that the development focus is on other elements right now. There's only 4 developers, so that focus is usually fairly narrow.
Here's a thread I was looking for earlier that may have made things clearer: http://www.vendetta-online.com/x/msgboard/1/16424#207671
Well that makes sense.. I have created models for other games and most of them have something similar with regards to how the model must interact with the game.. It's never as easy as slapping in a new model.
I'd still be curious to know how many polygons they think they could do for a single ship..
Or how many UV textures each ship can have..etc..
I'd still be curious to know how many polygons they think they could do for a single ship..
Or how many UV textures each ship can have..etc..
I know there's been a discussion of poly counts, but I can't recall anything about UV textures. I'll look around.
The number of polygons at this point should be largely moot.. Modern hardware is such that you can have a Loooot of polygons going at the sametime without much slowdown..
Guess they wont give us that information..
VO runs on less modern hardware, which is a big help for some players. Also, with 200+ ships in a sector as happens with some of the larger missions, it starts to matter more.
I'm all for some new graphics, but I really want the devs to fix the fact that you can hit and run with impunity first, and then fix the economy, introduce player-owned capships and stations, give us some new weapons to play with and somehow re-balance how power cells and grid usage work.
I'm all for some new graphics, but I really want the devs to fix the fact that you can hit and run with impunity first, and then fix the economy, introduce player-owned capships and stations, give us some new weapons to play with and somehow re-balance how power cells and grid usage work.
The issue Zak is that the game looks dated. That's bad. With a host of new FPS Space based MMO games about to hit the market, now is the time for them to fix that -- or fail.
Up until now they have been pretty much the only one, soon not so much.
Up until now they have been pretty much the only one, soon not so much.
We're actually not against people contributing art assets. We just haven't run across very many people who would wholly contribute their work for free (signing over all IP rights), while also having the experience necessary to make high-quality artwork. We have a lot of players who know how to model, but who often don't understand the difference between polygon-modeling vs actually creating complete content (a model takes about an hour for someone experienced, a complete asset usually takes a couple of weeks).
In answer to your technical questions though:
Smaller "fighter" type ships are best kept under 2000 polygons.
Larger "capital" type ships are upwards of 5500 polygons or thereabouts.
In either case, we also use LOD meshes (sometimes hand-modeled for optimal poly usage, but UVW must be the same to use original-texture mipmaps).. the capships need three or four (down to around 300 polies or so for the greatest distance). Two or three for fighter ships is acceptable (down to the minimum number to convey the basic shape). Prototyping the transitions between the LODs takes some time, to be sure visual popping is at a minimum.
Our engine also supports Hughes Hoppe Progressive Mesh Degradation, which was a great idea back in '99, but isn't that useful now due to advancements in hardware acceleration that benefit from fan/strip/cache-optimized, static meshes. So we mostly use static content now, and static LODs as mentioned above, unless it tends towards a really "round" shape with a truly massive number of highly-tessellated polygons (like, say, some of our asteroids).
Obviously, any mesh should make very good use of the polygons it has, have thought put into the smoothing group definitions (very important, especially with normal maps!), and be free of any problems like floating verticies, holes, flipped normals, ugly "crimped" polygon boundaries, and so on.
Each ship needs to have (at least): diffuse, specular, illumination, and normal (tangent space). Additionally, we have different regions set aside in a proprietary alpha format for dynamic coloration. Now anyone can create the above maps, but making something that looks really good is more of the.. issue. We know we have some art assets that are quite dated and need to be replaced. Ships like the "Raptor" represent the minimum level of artistic detail and quality that is required of any new asset. All assets must use single-textures, 512x512 for a smaller ship, up to 1024x1024 for a capital ship (but it had better make *great* use of that space to justify the memory overhead juggling we'll then have to do to keep players from texture thrashing). Our engine only supports power-of-two textures (512x512, 1024x128, but not 384x768). As a reminder, here is what the Raptor looks like (albeit without the dynamic coloration):
http://images.vendetta-online.com/extras/raptor.widescreen.png
(Be sure to zoom in to 1:1 screen resolution, as most browsers use poor-but-fast scaling algorithms, losing a lot of detail).
Stylistically, it's also possible to create quality content that we just don't think fits with our title. Concept art was traditionally used to get across these ideas before the content was created, but other methods could be used. Or one could just roll the dice. Either way I cannot guarantee that anything anyone creates will go into the game.
Our prototyping pipeline is only compatible with 3D Studio Max (we actually use older Max 7). One can model in anything and then export/import to Max if one desires. Beware of UVW coordinates and things when doing export/imports, they can sometimes get messed up (depends on formats and programs involved).
Once a ship is visually constructed, a collision hull must be hand-modeled. This is not very difficult, it's just another low-poly model, keeping in mind the collision usage and the fact that it defines the distribution of mass throughout the ship. Also, really sharp angles (wings and things) can result in some issues with our collision response setup, so we tend to "box" them a bit so they aren't that sharp. For capital ships that have complex hull designs (like the Teradon, for instance), two collision hulls need to be modeled, one with a close visual-equivalency for the client, and a rougher minimum-poly-count version for the server.
Then the actual weapon positions (ports) are defined, which uses 3DS Max "point helper" objects with specific information placed in the Properties->User Defined area. Engine positions are done similarly. Then the engine effects need to be tweaked for the given ship type, to look correct.
Then the ship needs to be scaled to the universe, which is usually done by comparing to existing assets, and calculating via a 10-to-1 "meter" conversion from what Max considers "1 meter" (ie, 10 meters in max is 1 meter in the game). Further testing and tweaking is usually required here.
To anyone who has created videogame assets, this will sound pretty vanilla / normal, and it is. However, it really depends on the background of the individual artist. The last guy we worked with as kind of a "free distance intern" (who made the Raptor, Constellation, and so on) had never worked with a shader-driven pipeline, and really struggled with making good use of normal and specularity maps and things. I had to send work back to him over and over again, or do it myself, which both frustrated him (and me) and was quite time consuming for the both of us. There was also a language barrier that made things more exciting.
I have standards that may be considered "high" by people who aren't actually in the game industry, and would be considered "standard" by anyone who is. Everything has to be clean, solid, and AAA quality. Textures should be built at 2x the intended X/Y resolution (1024x1024 for an intended 512x512) with full multi-layer PSDs submitted along with the flattened "final" version. Some companies don't believe in doing this (creating textures at higher resolution), but having made that choice early-on is the only reason our bumpy "bone" asteroids don't look dated (despite being 9 years old). The newbie training sectors still look pretty cool, for being filled with 9-year-old asteroid assets (the big one attached to the station notwithstanding, it doesn't look great).
Actually creating ships for the game requires a great deal of prototyping and testing, some of which is time consuming. The weapon "port" positions is a good example.. we usually create far more ports than we expect to actually ever use, just to have them in the model, and we extensively test the positions of the ones we do expect to be used.
Once one is completely trained in the pipeline, and assuming one is already an experienced game-company-quality 3D artist, it should only take a week or two to roll out a new ship. If one is really working full time and really has the pipeline down, even a little less than a week. It usually ends up that there's enough fiddling and tweaking of textures, or sending for approval and someone (like me) saying something like "specularity and normal aren't complimentary enough, make the scratches in the diffuse really shine through".. that time flies.
The problem here, in terms of taking the time to train people, is that I've been burned before. I spent several man-months doing little but helping the previous contributing "distance intern" in how to create content for our game, through language barriers and so on. It took over half a year for him to really begin to "get" it, to the point where I didn't need to spend a week just in cleaning up and fixing everything wrong with all the content he was sending me (and he had previously worked in the game industry, and was an experienced 3D artist). And then, after he "got there", he kinda freaked out on me and quit. So, basically, yes, we got a few nice ships out of it, but I spent one hell of a lot of time, and could have done the work myself with less effort.
Plus, as I stated before, you have to be willing to sign over complete IP rights to any content you create. With our interns we usually have a verbal agreement that they can use renderings/depictions of the work they create in their portfolio or demo reel in the future. But aside from that, we own it.
Finally, I feel I should reinforce an earlier point.. we have many players in our community who model. I have not seen any actual finished ships created by anyone (other than Luis, who as I said, made the Raptor and such) that I would actually put in the game. Sometimes there is a justification of something like "well it's not any worse than <enter crappy looking existing ship here>". That doesn't wash with me, I know some of our assets aren't the best, but I'm not going to replace them with anything less than the best. I'm also not going to add new ships that don't live up to the same standards.
If all that sounds cool with you, you should probably at least join the PCC (left hand side, under Community, or click here). We don't really have a "PCC for people modeling stuff", but it's at least a starting point in terms of our internal player-contributing community.
In answer to your technical questions though:
Smaller "fighter" type ships are best kept under 2000 polygons.
Larger "capital" type ships are upwards of 5500 polygons or thereabouts.
In either case, we also use LOD meshes (sometimes hand-modeled for optimal poly usage, but UVW must be the same to use original-texture mipmaps).. the capships need three or four (down to around 300 polies or so for the greatest distance). Two or three for fighter ships is acceptable (down to the minimum number to convey the basic shape). Prototyping the transitions between the LODs takes some time, to be sure visual popping is at a minimum.
Our engine also supports Hughes Hoppe Progressive Mesh Degradation, which was a great idea back in '99, but isn't that useful now due to advancements in hardware acceleration that benefit from fan/strip/cache-optimized, static meshes. So we mostly use static content now, and static LODs as mentioned above, unless it tends towards a really "round" shape with a truly massive number of highly-tessellated polygons (like, say, some of our asteroids).
Obviously, any mesh should make very good use of the polygons it has, have thought put into the smoothing group definitions (very important, especially with normal maps!), and be free of any problems like floating verticies, holes, flipped normals, ugly "crimped" polygon boundaries, and so on.
Each ship needs to have (at least): diffuse, specular, illumination, and normal (tangent space). Additionally, we have different regions set aside in a proprietary alpha format for dynamic coloration. Now anyone can create the above maps, but making something that looks really good is more of the.. issue. We know we have some art assets that are quite dated and need to be replaced. Ships like the "Raptor" represent the minimum level of artistic detail and quality that is required of any new asset. All assets must use single-textures, 512x512 for a smaller ship, up to 1024x1024 for a capital ship (but it had better make *great* use of that space to justify the memory overhead juggling we'll then have to do to keep players from texture thrashing). Our engine only supports power-of-two textures (512x512, 1024x128, but not 384x768). As a reminder, here is what the Raptor looks like (albeit without the dynamic coloration):
http://images.vendetta-online.com/extras/raptor.widescreen.png
(Be sure to zoom in to 1:1 screen resolution, as most browsers use poor-but-fast scaling algorithms, losing a lot of detail).
Stylistically, it's also possible to create quality content that we just don't think fits with our title. Concept art was traditionally used to get across these ideas before the content was created, but other methods could be used. Or one could just roll the dice. Either way I cannot guarantee that anything anyone creates will go into the game.
Our prototyping pipeline is only compatible with 3D Studio Max (we actually use older Max 7). One can model in anything and then export/import to Max if one desires. Beware of UVW coordinates and things when doing export/imports, they can sometimes get messed up (depends on formats and programs involved).
Once a ship is visually constructed, a collision hull must be hand-modeled. This is not very difficult, it's just another low-poly model, keeping in mind the collision usage and the fact that it defines the distribution of mass throughout the ship. Also, really sharp angles (wings and things) can result in some issues with our collision response setup, so we tend to "box" them a bit so they aren't that sharp. For capital ships that have complex hull designs (like the Teradon, for instance), two collision hulls need to be modeled, one with a close visual-equivalency for the client, and a rougher minimum-poly-count version for the server.
Then the actual weapon positions (ports) are defined, which uses 3DS Max "point helper" objects with specific information placed in the Properties->User Defined area. Engine positions are done similarly. Then the engine effects need to be tweaked for the given ship type, to look correct.
Then the ship needs to be scaled to the universe, which is usually done by comparing to existing assets, and calculating via a 10-to-1 "meter" conversion from what Max considers "1 meter" (ie, 10 meters in max is 1 meter in the game). Further testing and tweaking is usually required here.
To anyone who has created videogame assets, this will sound pretty vanilla / normal, and it is. However, it really depends on the background of the individual artist. The last guy we worked with as kind of a "free distance intern" (who made the Raptor, Constellation, and so on) had never worked with a shader-driven pipeline, and really struggled with making good use of normal and specularity maps and things. I had to send work back to him over and over again, or do it myself, which both frustrated him (and me) and was quite time consuming for the both of us. There was also a language barrier that made things more exciting.
I have standards that may be considered "high" by people who aren't actually in the game industry, and would be considered "standard" by anyone who is. Everything has to be clean, solid, and AAA quality. Textures should be built at 2x the intended X/Y resolution (1024x1024 for an intended 512x512) with full multi-layer PSDs submitted along with the flattened "final" version. Some companies don't believe in doing this (creating textures at higher resolution), but having made that choice early-on is the only reason our bumpy "bone" asteroids don't look dated (despite being 9 years old). The newbie training sectors still look pretty cool, for being filled with 9-year-old asteroid assets (the big one attached to the station notwithstanding, it doesn't look great).
Actually creating ships for the game requires a great deal of prototyping and testing, some of which is time consuming. The weapon "port" positions is a good example.. we usually create far more ports than we expect to actually ever use, just to have them in the model, and we extensively test the positions of the ones we do expect to be used.
Once one is completely trained in the pipeline, and assuming one is already an experienced game-company-quality 3D artist, it should only take a week or two to roll out a new ship. If one is really working full time and really has the pipeline down, even a little less than a week. It usually ends up that there's enough fiddling and tweaking of textures, or sending for approval and someone (like me) saying something like "specularity and normal aren't complimentary enough, make the scratches in the diffuse really shine through".. that time flies.
The problem here, in terms of taking the time to train people, is that I've been burned before. I spent several man-months doing little but helping the previous contributing "distance intern" in how to create content for our game, through language barriers and so on. It took over half a year for him to really begin to "get" it, to the point where I didn't need to spend a week just in cleaning up and fixing everything wrong with all the content he was sending me (and he had previously worked in the game industry, and was an experienced 3D artist). And then, after he "got there", he kinda freaked out on me and quit. So, basically, yes, we got a few nice ships out of it, but I spent one hell of a lot of time, and could have done the work myself with less effort.
Plus, as I stated before, you have to be willing to sign over complete IP rights to any content you create. With our interns we usually have a verbal agreement that they can use renderings/depictions of the work they create in their portfolio or demo reel in the future. But aside from that, we own it.
Finally, I feel I should reinforce an earlier point.. we have many players in our community who model. I have not seen any actual finished ships created by anyone (other than Luis, who as I said, made the Raptor and such) that I would actually put in the game. Sometimes there is a justification of something like "well it's not any worse than <enter crappy looking existing ship here>". That doesn't wash with me, I know some of our assets aren't the best, but I'm not going to replace them with anything less than the best. I'm also not going to add new ships that don't live up to the same standards.
If all that sounds cool with you, you should probably at least join the PCC (left hand side, under Community, or click here). We don't really have a "PCC for people modeling stuff", but it's at least a starting point in terms of our internal player-contributing community.
Can we sticky this thread now? I think incarnate's post is probably a great summary for this oft-asked question.
I'll link to the post from a separate sticky thread.
@incarnate: Great response man, thank you for addressing all my points and answering all my questions. THIS is the reason VO rules.. The fact that you can talk directly to one of the developers is great. I'm a software engineer for IBM and we can never talk to our customers, even though we would like to..
Now having said that, none of the language you used was foreign to me. It was pretty straight forward.
The majority of the modeling I have done in Modo and Lightwave was done for film not for games.. So I am used to having a limitless number of polygons at my disposal.. Thus models ranging in the hundreds of thousands of polygons weren't unheard of..
Games wise, I have created only 2 models for Operation Flashpoint and enjoyed that. They had some of the same issues with launcher nodes, thrust nodes, game engine greebles.. However they only supported UV maps. (OFP didn't even do normal maps.. sheesh.. BTW if you do redo your engine, look into parallax mapping.. its pretty keen.. )
The raptor that your previous art contributor gave look very nice.. Sorry he screwed you.. that sucks.. I hope you don't have a bad feeling about everyone because of one person.. I certainly understand your reluctance to indoctrinate someone new to your production pipeline considering your past experiences..
As to your requirements, they seem perfectly reasonable to me.. would you be willing to help the community by providing texture examples?
Take the raptor.. I don't expect you to give away the model but I'd like to see the diffuse, specular, illumination map? I know what each are and what they should be for film, but that might not be the case with games..
Also would you consider creating a small model viewer utility or maybe telling someone how to import and test a model in the game client?
Now having said that, none of the language you used was foreign to me. It was pretty straight forward.
The majority of the modeling I have done in Modo and Lightwave was done for film not for games.. So I am used to having a limitless number of polygons at my disposal.. Thus models ranging in the hundreds of thousands of polygons weren't unheard of..
Games wise, I have created only 2 models for Operation Flashpoint and enjoyed that. They had some of the same issues with launcher nodes, thrust nodes, game engine greebles.. However they only supported UV maps. (OFP didn't even do normal maps.. sheesh.. BTW if you do redo your engine, look into parallax mapping.. its pretty keen.. )
The raptor that your previous art contributor gave look very nice.. Sorry he screwed you.. that sucks.. I hope you don't have a bad feeling about everyone because of one person.. I certainly understand your reluctance to indoctrinate someone new to your production pipeline considering your past experiences..
As to your requirements, they seem perfectly reasonable to me.. would you be willing to help the community by providing texture examples?
Take the raptor.. I don't expect you to give away the model but I'd like to see the diffuse, specular, illumination map? I know what each are and what they should be for film, but that might not be the case with games..
Also would you consider creating a small model viewer utility or maybe telling someone how to import and test a model in the game client?
Happy the response was useful. I did previously put online an example of the ship textures (in that case, for the Prometheus). That wiki is now gone, but regardless, the old example was a bit out of date as it used object-space normal maps and the like.
We've talked about parallax mapping, as well as adding shadow support, HDR, and more complex dynamic lighting models.. but gameplay has held sway on development time, to date.
We do also have a viewer utility, which I currently have someone in the playerbase testing, with the idea of making it available to PCC members. It would remain kind of a "not for general distribution" sort of thing, and the maps might have the same restrictions, but I have no problem with doing both as a PCC-only kind of thing. The viewer can also be used to create visual effects (explosions, shots, trails, jump-animations, and so on). The downside is that the whole thing is totally undocumented, and has the umm.. user-friendliness of something developed by a programmer to be used by programmers. But all that aside, I thought I could throw together a basic README and let people give it a try.
So, yes, I'm open to doing all of that, but probably only to the PCC for now. You're welcome to join.
We've talked about parallax mapping, as well as adding shadow support, HDR, and more complex dynamic lighting models.. but gameplay has held sway on development time, to date.
We do also have a viewer utility, which I currently have someone in the playerbase testing, with the idea of making it available to PCC members. It would remain kind of a "not for general distribution" sort of thing, and the maps might have the same restrictions, but I have no problem with doing both as a PCC-only kind of thing. The viewer can also be used to create visual effects (explosions, shots, trails, jump-animations, and so on). The downside is that the whole thing is totally undocumented, and has the umm.. user-friendliness of something developed by a programmer to be used by programmers. But all that aside, I thought I could throw together a basic README and let people give it a try.
So, yes, I'm open to doing all of that, but probably only to the PCC for now. You're welcome to join.
I'm pretty sure that Inc's description of Luis
The last guy we worked with as kind of a "free distance intern" (who made the Raptor, Constellation, and so on) had never worked with a shader-driven pipeline, and really struggled with making good use of normal and specularity maps and things. I had to send work back to him over and over again, or do it myself, which both frustrated him (and me) and was quite time consuming for the both of us. There was also a language barrier that made things more exciting
doesn't translate to
Sorry he screwed you.. that sucks.. I hope you don't have a bad feeling about everyone because of one person.
[EDIT]Inc. is entirely correct; I was having a tl; dr moment.[/EDIT]
The last guy we worked with as kind of a "free distance intern" (who made the Raptor, Constellation, and so on) had never worked with a shader-driven pipeline, and really struggled with making good use of normal and specularity maps and things. I had to send work back to him over and over again, or do it myself, which both frustrated him (and me) and was quite time consuming for the both of us. There was also a language barrier that made things more exciting
doesn't translate to
Sorry he screwed you.. that sucks.. I hope you don't have a bad feeling about everyone because of one person.
[EDIT]Inc. is entirely correct; I was having a tl; dr moment.[/EDIT]
I think the description he was referring to is actually further down:
The problem here, in terms of taking the time to train people, is that I've been burned before. I spent several man-months doing little but helping the previous contributing "distance intern" in how to create content for our game, through language barriers and so on. It took over half a year for him to really begin to "get" it, to the point where I didn't need to spend a week just in cleaning up and fixing everything wrong with all the content he was sending me (and he had previously worked in the game industry, and was an experienced 3D artist). And then, after he "got there", he kinda freaked out on me and quit. So, basically, yes, we got a few nice ships out of it, but I spent one HELL of a lot of time, and could have done the work myself with less effort..
ANYway, no, I don't harbor any ill-will against Luis, and I appreciate the time he spent and the work he did; but I definitely am a bit more circumspect and do guard the time I dedicate to "uncertain prospects", when it comes to interns and the like. As far as the discussion at hand, that's not really a big deal, as we're talking more about documenting things for the PCC and then just letting people play.
The problem here, in terms of taking the time to train people, is that I've been burned before. I spent several man-months doing little but helping the previous contributing "distance intern" in how to create content for our game, through language barriers and so on. It took over half a year for him to really begin to "get" it, to the point where I didn't need to spend a week just in cleaning up and fixing everything wrong with all the content he was sending me (and he had previously worked in the game industry, and was an experienced 3D artist). And then, after he "got there", he kinda freaked out on me and quit. So, basically, yes, we got a few nice ships out of it, but I spent one HELL of a lot of time, and could have done the work myself with less effort..
ANYway, no, I don't harbor any ill-will against Luis, and I appreciate the time he spent and the work he did; but I definitely am a bit more circumspect and do guard the time I dedicate to "uncertain prospects", when it comes to interns and the like. As far as the discussion at hand, that's not really a big deal, as we're talking more about documenting things for the PCC and then just letting people play.
I'll apply to the PCC once I meet the minimum requirements. Until then, see ya in space..