in frontier you had several different start positions too, and one was with a Cobra mk3, but no auto pilot, while the other start position was on Mars, the and final one on Lave

but yeah, three start positions with three types of ships, I see this working

I like this idea

Thinking a little more about this......

Also, with the 3 starting positions, you could have an "Easy" option of the first ship, fully outfitted (listed above) in a safe system with a totally clean criminal record, a "Normal" option with the Eagle LRF with an adequate equipment level in a slightly unsafe system with some petty fines (say around a couple of thousand credits) to pay off and finally a "Hard" option with the Cobra MkIII with just basic onboard equipment in a very unsafe system with big humongous fines.

This is more than a compromise, it gives the player a real choice on how difficult they want the start of the game to be.

frontier did similar, and pretty sure one of the harder starts, cobra, you had fines too, so yeah, adding fines to the game would make it more interesting, especailly if there are bounty hunters after you for the hardest setting

edit

loaded up frontier, the cobra start point, had you as a fugitive in the federal and imperial systems

edit 2

thinking about start points more, (probably should be in its own thread) but for the easy start, pirate ambushes should be very rare, if ever, as you should be in a safe policed areas,

the second start point with the eagle mk1, ambushes should be more common, say 1/10 chance, or maybe a bit lower

while the cobra start point should see you wanted by bounty hunters and pirates, and your only refuge from the law are disputed systems, lawless and survival of the fittest, and ambushes should 1/3

I guess this could be more balanced once the game is in beta, but I think this would allow people either a very easy start to the game, or if they never played frontier before, or those that have and want a harder start use the second start point, while those that want the hardest and greatest challenge, use the third start point

I think that would allow the game to be more flexible, while still remaining easy for new inexperienced players

Better give finished models sonner than later and post links to our issue on github.

One of our game starts will ultimately be the one described in issue 374. It'll be the one I use when I start my first "real" game after all this testing.

I second that 🙂

WOW that would be a tough start, lots of smaller goals before really opening the game up. I guess, since the capacity is there within the game to allow you to make money without leaving a system, then yes I third that too 🙂 4 start positions then, easy, normal, challenging and hardcore? I mentioned this before, I think there should be a special achievement that is recorded within the game if you manage to take to the stars after such a difficult start.

Perhaps we should call it the Brianetta Award, because he's sure to be the first person to achieve it! 😆

Don't count on it. I'll be distracted by the flying.

4 starts seems OK for me,

A few questions about contributing with models.

For the engine, what should be the best polycount a space ship (regardless of its size) should be ?

I'm used to make low poly models in Blender, but if starting detailling a bit the shapes, it's easy to get the face count going high in no time.

By example i model this very low poly shape, it is indeed very simple

Now if i start to detail it a bit like this :

polycount is going to be obviously increasing and last thing i want is to get the engine crawling.

So at what kind of polycount a space ship model is considering good for Pioneer ?

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

I mean by example for this shape :

Would this be acceptable :

Or is it necessary to make this :

Finally, is Pioneer using a LOD system for the models (i mean level of details in which a model may be more or less detailled depending on the distance between it and the player) , would solve the polycount optimisation problem, as i could model many kind of LODs so a space ship would be detailled (in a reasonnable way though) visually only when the player is close to it

Now question about the textures, it's obvious that for a 3D model, less texture by models = better, so it's always more efficient for performance to have a model using only 1 texture.

So in the case in which more that 1 texture is needed for a model, what would be the absolute maximum to keep the model efficient with the Pioneer engine ?

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 ?

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 ?

edit : and remembering that all the engine i made contributions for always required specific licenses for the added content, what is required for Pioneer models/textures , does it need to be all-GPL like for Flightgear (non GPL content being only then available as 3rd party download) , or would Creative Commons (or even more restrictive licenses) acceptable/required for inclusion in the main releases ?

1.) For lod 1 aka collision mesh lower better. No need to export UV to collision obj. For other lods 2-4 you just add meshes with more details, lod 4 is with the highest detail.

2.) If your ship is going to use more than one material you must separate objects that are going to use different material. (use_material() in lua). You are free to do with faces/shapes what ever you want just note that everything should be triangulisated - when exporting obj.

3.) You can use as much textures as you want, more importans is size of texture - both in pixels and MB. 1024x1024 should be enough.

4.) You are free to add you own lights. This is done from lua.

5.) More info is available on pioneerspacesim dev wiki and on irc.

A slight addendum to this, modern graphics cards/drivers hate small meshes/textures.

It's much more efficient and future proof if the model has been welded into a single mesh wherever possible and the textures/materials that it used turned into texture pages/atlases (i.e. many textures within a single larger texture).

If we ever want to get to the point where we have larger numbers of ships in a single area than the current maximum I've seen of 3 (!) then we'll probably need to start adopting more rendering friendly modelling approaches.

I 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".

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:

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:

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.

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.

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.

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.p ... _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.

I know that sometime Pioneer can have draw depth problems

I 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 triangles

Under 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.

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.

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.