i didn't mean any harm by worrying about the tar.gz release, it was just my experience very recently and in the past that they are usually not as well thought out or packaged as the OOlite ones are.
No worries, I know what you mean. Some stuff works really well like Oolite, but I've struggled with other software as well.
jackiebean wrote:
but most of the ones that are pieces are modular and some im not sure why other than it was a challenge.
I'm going to have to check out blender, in wings3D I struggle with creating textures that Obj2DatTex.py recognizes. If I try to unwrap models one piece at a time Obj2DatTex won't apply my texture. Says texture coordinates not provided so I have to unwrap the whole model all at once. Unfortunately with more complex models wings often creates a texture with distorted faces and its hard to get a nice looking texture. So I end up breaking the model up into parts that wings will unwrap correctly.
jackiebean wrote:
I wonder if breaking the hull up into sections could get it to behave closer to some of the racing games that show damage to a car?
I toyed with the idea of creating ships with physical shields (frangible sub-entities) that could be blown off to make the inner hull easer to hit. Seems like this would work for simulating damage to specific areas of the ship.
Blender is really cool as far as texturing goes. Not only can you mark logical seams yourself by selecting the edges you want as seams (good for obj/material conversion) but you can also use a plugin called smart UV project that automatically breaks the faces into sections that can easily be textured. that is how i do my ambient occlusion UV. i use smart UV to unwrap it, and then AO bake. I don't even have to mark seams to use that plugin. Now granted my work flow is not as slick as other people, but once i get the particulars worked out and decide how i want the final model to behave (like frangibles/modular pieces/turrets/visible upgrades/etc) then i can mark seams and re-unwrap using smart UV and use the ao as the base for the actual diffuse/normal/glow/specular textures. now of course putting unique name/number textures would probably still need separate panel models, but those could also be randomized by texture only with a little creative scripting and some kind of logarithm instead of using several plane models for each name. However that only really works well on large ships and not so well on smaller ones. Scripting is kind of greek to me but naming/numbering like that has been done before in other games. The oolite engine is pretty adaptable so since scripting is used well already, it is probably not as hard to implement as other engines.
Back to blender, a few other nice features are the smooth faces and mark edges sharp. this gives the illusion of much more complexity on a lower poly model.
Granted blender is counterintuitive for 3daMax users (like myself who didn't like Blender at first) but once you get the controls down, it really is a breeze to work with and just as versatile as Max. Yes i miss some of the stuff in Max (not the price tag, and clunky Linux compatibility), but there are parallels in Blender, it just is not always the same method to achieve the same results. Blender has come a long way since the early days, and it is much less like Lightwave and more its own animal now. Give it a chance and it will probably surprise you like it did me.
Now i do understand the limitations of wings3d. and it is a great tool to use (i have it myself) so i am not knocking it at all. You can always export as an obj and import those to blender too. I also understand sometimes with stations and modular ships breaking things up to parts is better for the engine (especially when you want more detailed models or more variety in modular stations). So that technique is very useful to keep in the toolbox even if it is not as necessary for making a fighter model in blender.
I guess another question i have is if there is any LOD implementation in OOlite. I don't see any indication of that, but for far objects it taxes the GPU less. If it is not possible then that is cool. Just wondered. If so that would mean more scripting and more models to push out for each ship. It is kind of a trade-off.
making physical shields, ie frangibles, would probably be more appropriate or dramatic with larger ships or stations. But yeah it would be cool to see on smaller ones too. May have to toy with that idea myself. Breaking up sections of faces into chunks on the same mesh sems like the way to go, but exporting it would mean breaking each ship up into separated models what have to be assembled via scripting, which i am much less comfortable with, and each damaged part would need to be sequenced as a/b/c/d so the next damage panel would replace the less damaged one. Seems like that is labor intensive. Im not sure if there is a parallel to die rolls in OOlite, i guess chance variables are sort of like that, but the amount of damage would have to correlate to a range of numbers for each level of damage displayed. yeah, labor intensive. Maybe that is best to roll out later in some kind of OXP update if it is possible to get it working.
Actually i was talking more about the model LOD, but texture LOD is also paired with that in most cases. Just not sure to what extent OOlite can use these features.
I think that is why most big production games tend to compartmentalize their dev team, and yeah scripting is the same for me, so i have a steep learning curve.
Yes, I did this a few years ago with my old Smivs'Shipset, the forerunner to The Classic Ships, and also used it in other OXPs of the time.
They showed damaged textures when the hull took damage (low energy) and went derelict (progressively shut down/switched off lights) if an escape pod was launched.
The 'going derelict' feature was carried over into The Classic Ships as it works really well and adds a lot to realism, but the damaged textures were abandoned. Although they worked well and were quite effective, it never really fulfilled its promise due to limitations in the game, mainly the inability to identify where on the hull a ship was being hit. In practice you could shoot the ship in one place but the damage appeared in a different place depending on the texture used. It is not possible to improve on this without NPCs having separate front and rear shields (at least) and the ability to select a damaged texture appropriate to the location of the hits.
Were subentities a thing at this time? From what I read from the wiki, it seems possible to set up subentities that could be destroyed, revealing a damaged texture. It would not be so accurate that you could carve your name on their hulls, but it could be enough to add visual damage to a few interesting spots (like thrusters, or the tip of wings), where the player is most likely to "enjoy" it.
In my very personal opinion, being able to blow off parts of the ship could be better since dogfights are often too fast to let you admire the details of the textures; they are often not visible at all anyway when you set your ambient lighting to a very low value (like what KeeperSky does). OTOH, a missing thruster or wingtip is something one can more easily notice.
I think the DTT Manta works that way: you can blow off the whole "wing" part, which is slightly annoying because it's actually the main part of the ship, so it gets harder to hit the ship once it is gone.
Yes,. sub-entities have been around for years, and they can be set to be blown off if that is what is wanted. This was obviously not an option for me though, as I was re-skinning the default shipset of the time, one-piece models with no sub-ents. What you describe is a valid process though, and is one I have used - the Interstellar Research Station in Xeptatl's Sword has one end blown off during a Thargoid attack and it is very effective.
To do this properly for all ships though would require dedicated new models of both the ship and the frangible sub-ents. And you would still have the problem which really killed off the texture-damage, the fact you can't tell where a ship has been hit. The texture-damage was designed as you suggest to show damage where it is most likely (nose and tail areas), and it worked well......if you could overlook the fact that shooting the front right corner would often leave damage at the rear of the ship etc.
To do this properly, there would need to be significant (I assume) changes to the core code, to allow hits to be registered accurately in terms of position on the ship.
Commander Smivs, the friendliest Gourd this side of Riedquat.
this.$HardShips_FindWhichSide = function(ship, whom, hit) { //which side of ship facing to whom or hit by whom
var side = -1;
var v = ship.position.subtract(whom.position); //cube face comparsions
var f = ship.vectorForward.angleTo(v);
var r = ship.vectorRight.angleTo(v);
var u = ship.vectorUp.angleTo(v);
// if( this.$HardShips_Debug ) player.consoleMessage(f+" "+r+" "+u);
var pi = Math.PI; //3.1416...
var pi2 = pi / 2; //1.5708...
var fw = true;
if( f <= pi2 ) fw = false; //small f
if( fw ) f = pi - f; //make comparable, either fwd or aft
var ri = true;
if( r <= pi2 ) ri = false; //small r
if( ri ) r = pi - r; //make comparable, either right or left
var up = true;
if( u <= pi2 ) up = false; //small u
if( up ) u = pi - u; //make comparable, either up or down
if( hit ) { //requested to hit side
//randomize which side get damaged around facing corner using the angle of the whom position
var min = 0.175;//do not randomize if in the center 10 degree cone of the best side (0.175=pi/180*10)
if( f < min ) f = 0;
else f = Math.random() * f / pi2; //as high odds to front or aft as low the f angle
if( r < min ) r = 0;
else r = Math.random() * r / pi2; //as high odds to right or left as low the r angle
if( u < min ) u = 0;
else u = Math.random() * u / pi2; //as high odds to top or bottom as low the u angle
} //if requested facing side then f, r and u remain unchanged
//side compares, new method using "make comparable" lines to find the smallest angle
if( f <= r && f <= u ) { //Front or Aft
if( fw ) side = 0; //Front
else side = 1; //Aft
} else if( r <= f && r <= u ) { //Right or left
if( ri ) side = 2; //Right
else side = 3; //Left
} else if( u <= r && u <= f ) { //Top or Bottom
if( up ) side = 4; //Top
else side = 5; //Bottom
}
return(side);
}
//old side compares without "make comparable" lines, leaved here to demonstrate complexity
// if( fw && ( ri && f >= r || !ri && f >= pi - r ) && ( up && f >= u || !up && f >= pi - u ) ) side = 0; //Front
// else if( !fw && ( !ri && f <= r || ri && f <= pi - r ) && ( !up && f <= u || up && f <= pi - u ) ) side = 1; //Aft
// else if( ri && ( fw && r >= f || !fw && r >= pi - f ) && ( up && r >= u || !up && r >= pi - u ) ) side = 2; //Right
// else if( !ri && ( !fw && r <= f || fw && r <= pi - f ) && ( !up && r <= u || up && r <= pi - u ) ) side = 3; //Left
// else if( up && ( ri && u >= r || !ri && pi - u <= r ) && ( fw && u >= f || !fw && pi - u <= f ) ) side = 4; //Top
// else if( !up && ( !ri && u <= r || ri && u <= pi - r ) && ( !fw && u <= f || fw && u <= pi - f ) ) side = 5; //Bottom
that sounds really interesting. I was also thinking my first ship, the scorpion AV would be a good test bed for proof of concept for blowing stuff off and damage decals/model parts. might play around with the modeling part of that today if i find time.
