Open smcameron opened 5 years ago
I tried to see if I could load these models: https://v-ktor.itch.io/space-ships
But when I open them with the mesh_viewer utility they are full of holes, I can’t figure out why.
If I hack together an mtl file I can get them textured, but still with the holes.
I also got: Unable to load texture 'share/snis/models/spaceships01//carrier01_emission.png': load_png_texture only supports RGB and RGBA
while trying to add the light texture as well. Not sure how to fix that.
Also I did not understand what the _normal.png files are for and if I can link to them somehow. For _specular.png this seems to match the map_Ks mtl keyword but I am not sure the game takes it into account.
I also get ignoring unknown data '5880':s 1
but as the game models also give the same output I guess that is no big deal.
Probably they are "non-manifold" in some way or other. Perhaps some triangles wind the wrong direction and are getting back-face-culled. Brief googling suggests you need to "recalculate normals" (ctrl-N in blender according to google) and possibly re-triangulate if the model contains Ngons (non triangular polygons). But that's just what google says. I do not really know how to use blender, and am not very good at 3d modelling. Another thing to do might be load it into meshlab. I think it might have some things to help fix non-manifold-ness.
Game doesn't handle specular maps (map_Ks). It handles only diffuse and emissive (map_Kd, map_Ke).
Wavefront obj files do not really support normal maps. However, there is an extension I added that allows you to put in "norm filename" into the .mtl file, however, I do not currently have any models that use it, and I do not know for sure that it works. (spherical normal maps for planets are a home-made special case). The normal mapping depends on the uv-mapping, so the normal map would have to conform to the same layout as the texture mapping, it doesn't have a separate uv-mapping (of course). The game does not support multiple normal map files or texture map files, that is to say, the entire texture map must be contained in a single image, and the entire normal map must be contained in a single file.
Another avenue you might explore is the models of oolite: http://www.oolite.org/ The game can read the ".dat" format that game uses (mostly), and some of those models have normal maps and fancy textures, although recently they have done a lot of work on their renderer and are moving to physically based modelling, so probably some of that stuff will be too fancy to be usable by SNIS. http://aegidian.org/bb/viewtopic.php?f=2&t=4494&start=5490
I had to triangulate the faces in blender to get the model to show up correctly. It looks good in the mesh_viewer.
I’m not sure how to add it to the game, is editing ship_types.txt enough?
What do you think about these models?
Here is the fixed version I did if you want to look at it through mesh_viewer: carrier01.zip
https://en.wikipedia.org/wiki/Oolite_(video_game) says Oolite resources are non-free ("CC-BY-NC-SA for resources") which is why I did not look into it further, not sure if it’s true for all resources.
Maybe look at Pioneer's (http://pioneerspacesim.net/) models. Repo here: https://github.com/pioneerspacesim/pioneer-assets.
Pioneer's art, music and other assets are licensed under the terms of the Creative Commons Attribution-ShareAlike 3.0 Unported License. See licenses/CC-BY-SA-3.0.txt for details.
They are .blend & .dds files. Probably need to convert.
Ah, hadn't noticed that about the oolite models, good catch.
The model looks good ... maybe a little cartoony with all the fins, and a bit too much like a single pilot ship blown up to mega-ship size. Seems like the windows especially are like a single pilot ship, and also would be cool if there were more windows lit up on the emission map, and the plain white color on the emit map would probably be better as a slight yellow or amber tint to match other lit things in the game more closely.
To add it to the game, yeah, add it to ship_types.txt, and put the model files in share/snis/models/carrier01/
And if you want the thrust flares to match the engines, a carrier01_scad_params.h file will need to be created to tell the game the number, relative position and scaling to use.
For example, swordfish.scad_params.h contains:
{ 3, { { 2.3, { { -20, 0, 0 } } }, { 1.5, { { -16.75, 0, 8.5 } } }, { 1.5, { { -16.75, 0, -8.5 } } }, } }
Which means there are 3 exhaust ports, and three rows describing the scaling, and x, y, z offset of those exhaust flares, generally arrived at empirically.
Also, snis_ship_type.h will need to be edited (that is, if you mean to add a new ship type rather than replace an existing model. Maybe replacing an existing model would be better.)
Also the model will need to be oriented with the front facing positive X, and Y up (or parameters in ship_type.txt to rotate it into correct orientation, but just having the model in the right orientation to begin with is preferable.) I believe this can be done in blender when you export the model.
Other places to look for models: OpenGameArt (Various Licenses) & SolCommand
Yeah, I've been playing around with a little astronaut from opengame art: https://opengameart.org/content/astronaut-1 Also a bit cartoonish.
I don't trust myself to pick something from SolCommand because there's too much on there that's obviously Star Wars stuff, etc. that can't possibly be free, and so the provenance of all of it is kind of tainted. What assurance is there that I won't accidentally pick something that turns out to not actually be free? I definitely don't have an encyclopedic knowledge of various fictional but copyrighted spaceship designs, so the fact that I don't recognize some design isn't sufficient. If they want to host actually free stuff, they should do a better job of curating the content.
SolCommand's added a few from various shows since last I was there. Most are his own unique creations.
@smcameron Replacing models might be better indeed.
What I’m a bit afraid of with the https://v-ktor.itch.io/space-ships models is whether they will look good as wireframe in the science screen and navigation. It’s indeed a bit hard to chose scale and estimated size of the crew.
You can preview what the wireframe will look like in mesh_viewer by pressing R.
It actually looks good in wireframe too.
Regarding pioneer assets, I think we could use these two: https://pioneerwiki.com/wiki/Malabar -> to replace the transport model, most likely https://pioneerwiki.com/wiki/Kanara_Interceptor -> But we already have the enforcer which is textured, so not sure what this one would replace. Supposed to be a small ship (they say 1 to 2 people in crew). Maybe the vanquisher?
When selecting a ship to replace, I wouldn't put too much stock in the names. Apart from a few (enforcer (police), asteroid miner (mining bot) and transport (used in the RTS mode) and mantis (tow ship -- needs to be a certain scale and shaped a certain way)) I think the names are more or less arbitrary. The properties like top speed, etc. in ship_types.txt are also malleable (not carefully balanced or anything, with some exceptions -- enforcer is fast enough to catch anything, for example).
To me, the ugliest current models are probably... battlestar, cruiser, destroyer, freighter, spaceship2, spaceship.stl, swordfish.stl -- so if you want to specifically swap out the transport model, I'd probably then move transport.scad to replace one of those other (to me) uglier ones.
That being said, there's some things remaining to be worked out about how to replace things. I'm not too keen to put giant models into git. It's not a big deal to put an openscad file into git because they are small and essentially code, which git is good at storing. But an stl file, or a .obj file, and accompanying textures ... I'd rather not put any more of those into git. I can of course put them onto spacenerdsinspace.com -- but this leads to the problem of producing unwanted "git diffs" if they actually replace any files. So I think I need to come up with a way to have models from spacenerdsinspace.com be able to supersede the models in git without actually touching any of the files in git.
Ok, I committed a simple system to replace assets (even if I eventually decide to move to something like git lfs, I figure this will be good for modding). It still needs a little work, in that it's a little fragile if you try to use non-default asset directories (fails by not finding the replacement assets and using the originals assets) and it currently only works for models and their textures, but not textures in general, though getting that to work also should be trivial.
Basically, if snis_client finds a file in share/snis/replacement_assets.txt, it reads it. Each line in that file maps an original filename to a new file name. Whenever assets are read, it checks to see if an original filename has been superseded, and if so, it reads the new one instead.
e607e55a285a3a38d8f5bcba2111f86efda0020f
I have put the carrier01 model on spacenerdsinspace.com and with the new replacement asset system, "make update-assets" will pick it up and replace transport.stl without causing any git diffs. I had to rotate and scale the model a bit. Also the thrust flares aren't quite right yet. Also I still need to work on dealing with asset_dir correctly.
So the license is Creative Commons Attribution v4.0 International : https://creativecommons.org/licenses/by/4.0/
However, the only name I have to attribute is "viktor", which seems not quite right. Would be better to have a real person's name.
@smcameron https://opengameart.org/content/spaceships-6 says that the author is "Viktor Hahn (Viktor.Hahn@web.de)"
Thanks.
I have now allowed *.scad_params.h files to be superseded and "make update-assets" will fix the scad_params.h file for the new carrier model.
It would be quite useful to have some way to render all ships from ship_types.txt next to each other. That would help fixing orientation and scaling problems, and to get an idea of which needs changes.
Not a bad idea. The orientation is easy to check. View it in mesh viewer, and initially it should be facing you, and upright. In mesh viewer, positive X axis is facing towards you, and positive Y axis is up, and positive Z is to the left. Not so easy to check them all at once though.
Possibly some modification of this python script and blender? https://blender.stackexchange.com/questions/39303/blender-script-import-model-and-render-it
Modifying mesh_viewer to have sufficient camera controls and the ability to render more than one model is a bigger job and will complicate it more than I really feel like tackling. Another approach would be to allow Lua scripts to clear everything, add all the ships one by one next to each other, make them all catatonic so they don't move, orient them all, and then move the player ship nearby, facing them. However, that's kind of a lot of work too. The blender approach seems like the least amount of work (or it would be, if I knew how to mix python and blender at all.)
Another approach would be to allow Lua scripts to clear everything, add all the ships one by one next to each other, make them all catatonic so they don't move, orient them all, and then move the player ship nearby, facing them.
This is what I had in mind, in order to get them with the ship_types.txt settings applied and to be sure that we see them as the game would. Lua scripts can already clear everything and add the ships, what part are missing? Being able to orient ships precisely might be useful to missions.
However, that's kind of a lot of work too. The blender approach seems like the least amount of work (or it would be, if I knew how to mix python and blender at all.)
Can’t really help here, I’m no good with blender nor python ^^
what part are missing?
The main part that's missing is a way to put the ships into a catatonic state so they don't just drive away.
@smcameron What if we give them a small patrol back and forth?
Just pushed a few patches. Now there's a lua script, REVIEW_MODELS.LUA https://github.com/smcameron/space-nerds-in-space/blob/master/share/snis/luascripts/REVIEW_MODELS.LUA
Awesome
I do not see the replacement model for transport I still see transport.stl
Are you running the game from the directory you compiled in, or did you install it?
I suspect it has to do with what I mentioned before about "Also I still need to work on dealing with asset_dir correctly."
I run from the root of the git, using ./snis_launcher to start everything.
Ah, ok. I was running with quickstart. I duplicated the problem with snis_launcher. snis_launcher sets SNIS_ASSET_DIR, and I think that's tripping over my "simpler than possible" replacement asset code.
Ok with quickstart it works, thanks!
I've pushed some changes to teach the asset replacement system about asset dir. You need "git pull" and "make update-assets" to get the new share/snis/replacement_assets.txt, but if by chance you've been say, editing models or model textures, or other asset files, do "make check-assets" first to see what would be updated, and move any such changes out of the way first so they don't get clobbered.
What about this as replacement of battlestar? It would need to be scaled to be pretty big (the smallest red squares on the side being the height of a human being)
And this is my attempt at exporting pioneer’s malabar to be the biggest transport ship in SNIS: malabar.zip (Same thing, would need to be scaled big, not sure how it is now) I may not have done it the right way, the blender file contained extra things and used lots of textures, I just applied the one named diffuse and ignored the others.
Ok. "make update-assets" to pick up the new battlestar. I scaled it up 5x and rotated it 180 about vertical axis.
Haven't looked at malabar.zip yet.
Ok, just looked at malabar. It doesn't look great in wireframe mode due to high polygon count (might be able to hammer on it with mesh_lab to fix that). The guns would not be functional... maybe that's fine.
How does current ships behave regarding guns? Is there a specific place on the ship the bullets are starting from? The wombat is the only one with a mobile turret right?
The wombat is the only one with a real turret, apart from the Demolisher, which isn't really a real ship. It has turrets on it though, and they work ... https://www.youtube.com/watch?v=RAboPRjI4Vg&t=19m00s
Some time ago I tried (unsucessfully) to allow mounting of those same turrets onto ships and starbases -- it should be possible, I probably have that patch still lying around someplace.
The torpedoes and laser beams and missiles just emanate from the center of each ship. Usually, when they fire they're far enough away that it's not particularly a problem.
Also, the NPC wombats do not have turrets.
Some texture packs we may want to use, with normal maps: https://opengameart.org/content/majestical-metal-sci-fi-station https://opengameart.org/content/metalstone-textures
Got this weird reading using review_models and looking at the ships in science screen.
Looks like a bug.
Also, I got a Battestar reading only 3 lifeforms on board, sounds highly unlikely. shouldn’t the default crew be close to maximum crew somehow? On the same topic, I was not expecting to read this many lifeforms on mantis (was expecting a small-to-no-crew ship), and I was not expecting to read lifeforms on MINER, shouldn’t it be completely automated?
When starting a solarsystem, which ships are placed randomly, all of them, or only a subset? I was expecting mantis, miner and maybe wombat to be excluded from random placement but I could not find the code for this.
Yeah, the multiple entreis for metallic ore looks wrong. Not sure what's up with that. Wasn't able to quickly duplicate it. I'll keep an eye out for that. I suspect o->tsd.ship.ncargo_bays got corrupted for that entity somehow.
I think the lifeform count should be initialized like so:
go[i].tsd.ship.lifeform_count = ship_type[go[i].tsd.ship.shiptype].crew_max;
The entry for battlestar in ship_types.txt is:
BATTLESTAR battlestar.stl - 0.8 1100 25 75 3 1 1 1 1.0
So the crew size should be 75, however there is a 3 right next to that 75 that is looking awfully suspicious. Maybe there is some bug with the ship type reading code that is somehow getting triggered by that line? I'll have to look into it.
All the ships are placed randomly. The asteroid miner did not start off life being the ship's mining robot, I just use the model for the asteroid miner ship as the mining bot model and the mining bot is really a ship that has a special behavior. So it has non-zero lifeform count as an oversight due to its previously life as a ship. When you hail a starbase and request a tow ship, the code searches through all the objects and finds the closest mantis to you (if any) and puts that ship into tow mode, and send it your way. If there are no mantis ships in the universe, then you're out of luck. There are NPC instances of the wombat flying around, you do not drive a totally unique ship. Well, your wombat has a turret, no NPC wombat has a turret.
There is definetely something wrong, I’m getting lifeform count inconsistent with ship_types.txt, and it seems to change depending on whether I start a mission script before calling review_models or not.
I also got the weird 0 ore bug a second time, on battlestar, but only two lines this time. Not sure how to reproduce it. May be related to starting a mission script messing with player cargo first.
@smcameron Seems like add_specific_ship creates the ship and then changes the type, but the type-depending stuff does not get updated.
That is at least shield_strength, lifeform_count, ncargo_bays, ship_registry.
I think the best fix is to do things the other way around, having add_ship call add_specific_ship and passing a random type to it.
Yeah, that does seem to be a problem. Thanks. I'll work on it.
Ok, I think the add_specific_ship problem should be fixed by b17308ac35baf6bc5acc36c68fea405cfbd4362a
Yep, battlestar correctly shows 75 people now.
Regarding ship scales, I would go for: Big ships: Battlestar (should be big enough to contain small ships), Transport (lots of people/cargo - model should be malabar), Mantis (must be able to tow other ships), cruiser03 (Look like transport ship as well…) Medium ships: Wombat, carrier01 (could be cruiser?), cruiser01, destroyer03 Small ships: police enforcer, miner (should be small enough to fit in wombat), frigate01?, frigate03?
You can adjust the scaling via ship_types.txt, there's an extra_scaling parameter for each ship.
Feel free to play around with it.
If the miner is small enough to fit in the wombat, you might not be able to see it. (Sometimes realism should take a backseat to playability -- whether this is one of those times, I don't know.)
Currently the only ship that ever gets towed is the wombat. So it's not stricly necessary that the tow ship should be able to tow a battlestar, for instance, or that the towship necessarily must be the biggest ship there is. (A normal tow truck cannot tow an 18-wheeler tractor trailer -- they have special giant tow trucks fo that.)
I am going to attempt to learn to uv-unwrap with blender.
If the miner is small enough to fit in the wombat, you might not be able to see it. (Sometimes realism should take a backseat to playability -- whether this is one of those times, I don't know.)
Indeed.
Currently the only ship that ever gets towed is the wombat. So it's not stricly necessary that the tow ship should be able to tow a battlestar, for instance, or that the towship necessarily must be the biggest ship there is. (A normal tow truck cannot tow an 18-wheeler tractor trailer -- they have special giant tow trucks fo that.)
Also true.
I’m hitting "max of 60 textures are already loaded" errors while trying out a few replacements
Now that we have shaders that can do normal mapping for more than just spheres, we could use some models that can actually take advantage of this.
Currently our models are mostly just some stl files generated via OpenSCAD, which is OK, but they lack even basic texture mapping, never mind normal mapping. We do have a few models with texture maps and emittance maps, but none with normal maps (other than some procedurally generated normal maps for planets.)
Spaceship models should be oriented facing down the positive X axis, with positive Y axis being up. Other orientations can possibly be accommodated but that is the preferred orientation. Scale should be on the order of 50 to 100 units long, though scaling is adjustable by the engine.