SpaceSimCentral

We don't have an established polygon budget. Feel free to help to test the limits However it is important that LODs are properly used.This would be suitable for LOD2:
Quote:

However for LOD1 you want to go simpler. It is shown from far distance and it is also the collision mesh. Something like this (outlined):I don't think this kind of fine detailing is too much close up, however it is lost from a distance so this should probably be LOD4:
Quote:

Then you'll need some intermediate step for LOD3. If it feels like too much work to do four levels - then lose some of the fine detail and go with three.
Quote:
Now for the structure of a space ship model : would there be problem if a space ship model is made of several part that are saved as if it was a single model, of would it be necessary to have the whole model not made from any part but from 1 single hull
The meshes do not have to be watertight so feel free to intersect shapes.Also, we only support one texture per mesh so you will need to split a multi-textured model into separate meshes.
Quote:
While i think about it and having noticed pulsating lights working, i am wondering, would then this kind of texture (with the lights actually be in that free texture found on a website) a big no in Pioneer ?

You can give the model a glowmap like this. See data/models/buildings/vlastan/ for our so-far only glowmap-enabled models. Glowmaps are not animated in any way though. If you want blinking lights they are something defined in the model.lua - they will be billboards/sprites.
Quote:
Finally, what's certainly the biggest obstacle for me, i have read in this thread that you need coding.Is there any kind of documentation on how to bring a space ship into the game , and what is exactly needed in term of vertex groups , naming etc to get the required anumations (gear, station doors, etc... ) working ?

Each model is defined in a lua script. The scripts are then compiled into a runtime format. Actually you can create your model entirely in lua - there's a whole much of commands for creating primitives, shapes, individual triangles... loading an .obj file just happens to be one of the commands. There are no vertex groups, proxy models or model naming tricks - thrusters, lights, and landing gears are positioned and animated in the lua script.I would say: don't worry about it now if you just want to model some cool ships. We do not have a step-by-step guide for making a usable ship right now. As learning material, we have:- This documentation/collection of notes http://pioneerspacesim.net/wiki/index.php?title=3D_Modelling- lua modelling functions are documented in some detail here (temporary host)- you can learn everything necessary from the existing models. Many of the scripts can be hard to understand though...We should come up with an example best-practices ship from the existing models or make a new one...

It's great to see Pioneer is supporting lods for 3D models.Thank you all for your answers, all of them will be helpfull.

fluffyfreak wrote:


Robsoie wrote:
Now for the structure of a space ship model : would there be problem if a space ship model is made of several part that are saved as if it was a single model, of would it be necessary to have the whole model not made from any part but from 1 single hullI mean by example for this shape : this be acceptable : is it necessary to make this : think the last approach is the better one to take, otherwise you could get z-fighting issues at the intersections. Also remember that polygons are single-sided (or they should be) modelling thin fins/wings/etc needs to be done with a mesh consisting of triangles on both "sides".


I know that sometime Pioneer can have draw depth problemsI have made models for the game Operation Flashpoint (from 2001) , and to avoid getting the face count exploding (that engine was not obviously in 2001 made for high poly content) i used the method that resulted in the less faces for the higher detailled lods, and obviously every other addon maker did the same.And i don't remember having observed z-fighting when the models were ingame..But if Pioneer has problem with z-fighting too, it can be rather annoying for when optimising face count :On -very- low poly certainly there's no real problem with the last approach, but when you start making details, the face count goes higher and higher with that last approach.By example, this shape :It's very simple as you can see, there are only few cubes.Now what happens if i must do the last approach, i end with this :96 vertices and 188 triangles.But if instead of the last approach i use the first one, i end with this :obviously same amount of vertices, 96 , but the face count is 122 trianglesUnder such low triangle count it seems not really important, but remember this example was only for a model made of only a few cubes, with a full fledged space ship, the difference in face count can become really high between the 2 method.

I just tried dropping a mega-ship model in comprised of 52,622 triangles and 27,015 verts that I'd welded into a single mesh... I suspect that's pushing it for the lower end cards Ok, obviously I picked a ridiculous model as an example, but I think people underestimate how fast their gpu is. If it's about 5 years old then you can expect it to handle ship meshes at around 15,000 to 20,000 triangles, that's assuming that we're rendering about 20 of them without terrain and still holding at 60fps. Halve that number for with terrain.Unfortunately we support much older cards, so perhaps 2,500 to 7,500 triangles is a better target. Suck it and see I guess, then see if people complain

The issue you mentioned have nothing to do with models.Lynx (ship on picture)have such problem because of using zbias() to put one texture on top of other texture and it also use zbias for models which is pointless.I did not made that model so I dunno why someone use zbias for something which is not designed for.If you remove all zbias calls in lynx lua the depth artifacts will be gone, but window texture will flicker..., obviously this is bug in model itself. Window should be another model called separately with own texture (obviously it can use same file) and own material.Also lynx is very dumb model with so small number of triangles.If you encounter any problem with your models in pioneer please provide obj and I will take look at it.

Robsoie wrote:
I know that sometime Pioneer can have draw depth problemsI have made models for the game Operation Flashpoint (from 2001) , and to avoid getting the face count exploding (that engine was not obviously in 2001 made for high poly content) i used the method that resulted in the less faces for the higher detailled lods, and obviously every other addon maker did the same.And i don't remember having observed z-fighting when the models were ingame..But if Pioneer has problem with z-fighting too, it can be rather annoying for when optimising face count :On -very- low poly certainly there's no real problem with the last approach, but when you start making details, the face count goes higher and higher with that last approach.By example, this shape :It's very simple as you can see, there are only few cubes.Now what happens if i must do the last approach, i end with this :96 vertices and 188 triangles.But if instead of the last approach i use the first one, i end with this :obviously same amount of vertices, 96 , but the face count is 122 trianglesUnder such low triangle count it seems not really important, but remember this example was only for a model made of only a few cubes, with a full fledged space ship, the difference in face count can become really high between the 2 method.
Z precision issues could conceivably appear when you zoom to look at far away models... But thanks to some magic tricks, Pioneer handles the situation without artifacts:That's LRC, our latest ship addition, basically a flying brick with some detail geometry added in the way you described above. I changed modelview FOV smaller to zoom.If you turn shaders off you will start to see flickering artifacts, it gets worse the farther you are:I don't know if this is a visible issue in normal gameplay (there is no zoom function yet) as I don't really test in the legacy no-shaders mode for extended periods of time.I don't think it's a big deal. Just model in a way that is the most productive.

I'm the one who actually made that ship. When I use modelviewer I always disable shaders and did not encountered that neither in pioneer.

unfortunately my machine is broken and i can't present what i was up to in the past 3 months.but it's "only" a broken gfx card (i assume) and no data is lost. it will only take some time.nice to see some new modelers have moved in.

Quote:
unfortunately my machine is broken and i can't present what i was up to in the past 3 months.
Welcome back Gernot! You have been missed. It wasn't too long ago we were discussing that really cool station you made a while back which we really must include with Pioneer.Edit// This is the one I'm talking about:

really too sad my machine is out of service,i haven't completed this one yet, but posted the actual wip once to rob?BUT! you should see the new one, based on the platform station (1-4 docking platforms), containing a little train that carries some cargo and runs around each platform. further a couple of new and old ships, such as "dr. zarkovs" ship from flash gordon or the bubble gum flavoured "planet express".some new own creations, and the long awaited robot pilot (mainly i made for the train).a pimped up "big crappy",btw, is that timer problem solved, it's really sad and most time relevant animations didn't work after the first month if i use gametime (get_arg(1-4)).realy sad i can't upload the "bloodrunner" (dr. zarkovs ship), it's somekind of a "time machine", containing clocks showing the different times (actually your local time and game time).there is a BIG second counter which shows exactly the manner of this bug or failure.to explain,in january seconds counts proper divisions of seconds (1000st part i guess).in february seconds count only quarter seconds (0.25, you smell allready something?)in march seconds count only half seconds,from on april you will have only full seconds get counted and no divisions, it's due to the nature of things not possible to divide that back. so many animations (like the beacon lights on the groundbase) won't work from february on. since they need at least the 10th part of a second to work.as another example , i made a sine based running light this won't also work if you have no proper divisions of seconds.actually most of my animations are due to that based on os.clock because it's the ONLY reliable counter i have.of course it's no problem if you count only whole seconds, but that will work only for some flashing lights in 2 seconds rythm (math.fmod(arg,2)i'm not shure but i feel it has something to do with the adding of 0.25 seconds.further i guess it's a older bug, it reaches back at least to alpha6 i experienced.oh, i made some radars, a bigger and a smaller one as starport buildings, they are still driven by gametime, it looks really stupid to see the small (faster one) ticking in seconds rhythm, that didn't means only the time it means also that you won't have any position between 60 integer steps on 360 degrees.

i guess, after reading the changes (i can't run pioneer on this macbook), that is already solved, sorry.no not sorry, i'm happy that it will work now, even if i can't try.

potsmoke66 wrote:
i haven't completed this one yet, but posted the actual wip once to rob?
Yes, I still have the PM, but the link (p66.live.com) is dead

sorry i wasn't aware, i must have deleted it, as i can't find that myself in the storage.well, that's useless, i MUST fix my computer very soon, else i'm getting crazy

Hi Gernot! Welcome back! I missed you! I'm looking forward to seeing what you've been working on. As for that pimped out big_crappy, I have a couple of vague ideas for it. The first is an iris door on each end of the entrance tunnel, and the second is to change the final docking position to correspond with the coriolis effect. The number of docking bays would be increased to six, and you would enter the bay, stop rotation until you lined up with your allotted bay, then settle down into it, seeing the other bays at sixty degree angles around you.I also wanted to mention that I made spacestations.lua self referencing. I put all the textures I lifted from you into a new folder, data\models\stations\textures. This is just in my version, it's not in the game, but may be in the future. I'm getting the two mushroom stations into shape for alpha 15. I'm thinking of trying to improve the hoop and other ground stations after that. I want to integrate whatever I do with your big_crappy!

Quote:
BUT! you should see the new one, based on the platform station (1-4 docking platforms), containing a little train that carries some cargo and runs around each platform.
Sounds cool I hope you can get your computer sorted soon..

i made a iris for the bloodrunner bridge :lol:not easy, how you planned to it? scripted?anyway it will work, but not perfectly if you use simple triangles, it will need some more experience.you can rotate a triangle for a iris blend if you set the axis on either left or rightside of the shorter side of a equal shanked triangle, if it's a scripted geometry it's simply start (v(0,0,0)) of the triangle (depends on which side it should move, left for a clockwise).the triangle should be reasonable a section of a circle in the desired size of the "door" (or whatever).now i tested the movement in blender before i started the model, and it showed that without correctional values in the rotational movement it will leave a little gap from on roundabout half of the way, when it opens.but it's rather small and deniable, imo.a solution could be if the section is a little oversized, but the rotational axis is kept on the proper size, each would overlap the previous a bit then.the texture idea is good, i allways thought once textures could be gathered together.it might not help for performance, but it helps for shure to keep it a bit smaller.it's cool imo, iv'e made a new seamless shiphull texture, meanwhile i used it for many different things because it's so multipurposal. a few more of such and many models won't need own texture sets.the texture i started for the "bloodrunner", because it's a original sketchup model and after converting of the geometry to collada, so i can read the model, they have usually a immense poly count, so i thought of something i can use in the way like i project textures on a scripted geometry, no unfolding, only one texture (almost), simple "project from view" uv.it really helps, imo (if i have a projection from view uv, the .obj file has also only one uv for all faces of the mesh).i'm not shure, but i guess sketchup models are like our scripted geometry, that's why they have this immense polycount.i had this idea after looking at the "bloodrunner" (dr. zarkovs ship), the tail looks like you would define a flat and a bezier quad after a bezier curve you have drawn as border of the shape.if i'm right, then there should be a better way to convert sketchup for pioneer, i preassume it uses only different commands for the same stuff (draw a shape...).really something that's still comes to my mind from time to time, a 3d modeling program for pioneer, using the advantages and limitations of scripted models (perhaps with the possibility to create scripts for .obj models, of course i could think, "hm your own fault if you can't handle that little text editing," but i understand it's pepperland for many).also i'm still convinced that it would be possible for a interested phyton scripter to create a blender script that exports our lua format models, finished with all the settings for thrusters and specs of the ship.that could be wavefront .obj still, only you don't have to mess around with especially the expressions for animations. because i'm pretty shure cad internally get the animations handled like we do, only that the program does all calculations for you, usually when you export a model to a animated model only the set keys of the animation will be exported.but i guess it should be also possible to read out the rotation and translate data as they are.

potsmoke66 wrote:
also i'm still convinced that it would be possible for a interested phyton scripter to create a blender script that exports our lua format models, finished with all the settings for thrusters and specs of the ship.

Yeah, It would make things nicer. I've done similar things with 3ds max in the past. No experience in Blender scripting though.I put it on the tracker, add comments if you have any: https://github.com/pioneerspacesim/pioneer/issues/655

Quote:
I have a couple of vague ideas for it
first i did was to eliminate the second lathe for the from front / from side projection by splitting it up topart models so i can project each side together and have only one model.i was noticing it while i was wondering why the text disappears when i'm close?ok, 1m added to cover the other mesh, but forgot to lift the text over the new mesh.after that i thought, why not "cleanup" the whole model?hm, you like to change the docking positions, well then my additional buildings won't fit.i only sticked 4 of my "coil buildings" into the hull (with a little modification of the building), now the lower parts sticks inside and it looks a bit like a docking pole/control tower.the wheel section i doubled and added some kind of a windows texture, not bad now, at least no longer "crappy" (i never felt).

My vague ideas are just a pipe dream at this point. I just thought I'd toss them out there for discussion. Yes, I was thinking lua scripted iris doors. I look forward to seeing what you have done, because it's sure to be an order of magnitude better than anything I'd be able to do. Although the stuff I did to it makes it live up to its name. I think I got the "crappy" part right!