The problem is not with GitHub, the problem is that most people are not used to use it. For one it requires an additional registration, which will probably put some people off, second they're not really knowing what they exactly sign up for, and third they are used to such things being restricted to developers. You put a request on the forum, it gets discussed in length, finally the devs decide to add or not to add it to the official features request list which is usually secluded from the average board member. That's the way it usually works, and that's the way most people assume it works. They don't expect that they can just go to GitHub and plant their silly ideas directly into the Dev's schedule without any prior review. It scares the hell out of you the first time. Like you'd have to take of your shoes when going over there or something. It's Developer territory, and newcommers are usually more comfortable to stay out of it, because you never know what an enraged Dev might do to you when you mess something up over there...

Of corse that's not the way you guys handle things. But it's the way newcommers expect things to be handled.

The other thing is, it's called an Issue tracker. My first thought when I saw it was "great, if I ever encounter a serious bug I can post it there. There's probably a long form to fill out about occurence and reproduction of the bug etc, but that's ok with me, I have expierience in reporting bugs". That was my first thought, and I have expierience with that kind of thing (which is probably why I supposed a long form to fill out for a bug report). It needed some continous prompting by the dev's for me to get over there, register and post "here's some small Ideas I had...". It's not what you expect to do on an issue tracker. There's always the slight fear of a Dev jumping out of a corner and screaming "Thou shalt not spam in our sacred roadmap!". At least the first few times.

Maybe a sticky named "how to make feature requests" and one on "how to send in contributions to Pioneer" shortly explaining the (not exactly usual) policies here would be a good thing. Sure, half of the people won't read it, but the other half will at least know exactly what they have to do, and that it's totally ok to do it.

EDIT: Point in case from the Alpha 16 thread:

See? That's me STILL thinking that it's common procedure to first get some confirmation for an issue on the forum before actually making it one. It doesn't come easy...

Ditto what UncleBob said. It takes some getting used to for non-programmer artistic types. That's why it takes so much coaxing to get us over there. 😀

p.s. No, I don't know of a better way. 😛

ok marcel, the solution is rather simple.

somehow "data/models/spacestations.lua" isn't empty, as i've planned it to be, to work around a additional deleting of it.

simply delete "data/models/spacestations.lua" it's the same file as "data/models/stations/spacestations.lua"

😳

edit: i will update the file of course

ground_stations_p66_nov2011_2.zip

[/hr]

coolhand if you move in, i can take my walking cane... 😆

i hope i didn't mismatched the scale of the viper... i can't exactly tell actually but i remember i rescaled only one fe2 conversion, the Constrictor, this only because if you compare the ships from viper over cobra to constrictor to asp the constrictor is nearly double in size as the asp, something's really wrong there. in FFE it get's even more worse and certain ships are complete out of scale, i.e. the "gyr" if i remeber right (re-scale for a ffed3d export is ~10x a little less or a little more, depending on what model you take as template, usually it's the wheel stations portal height).

btw, i can see no problem keeping the viper or other rebuild Frontier ships, just my transscriptions are very, very close to the original and that could be a problem once. further a simple rescaling won't change that (i.e. for the Eagles), every vector is identical to the original data.

scaling in FE2 is a lucky throw sometimes. of course it's bound to the fact that FE2 uses only integer values for the models geometry, that means you have to find a more or less fitting size in integer vector values and rescale the model to the game worlds scale, sometimes it was a bit made by choice or looks of the ship imho. on the other hand i understand that it's anything else then easy to find the proper size if the ships (all models) have very different mesh sizes and you couldn't simply compare them in a CAD like we can do now. further, by the way models get scaled in FE2 i'm not sure if all models get drawn or exported in the proper scale by FFED3D, the scaling in FE2 is dynamic, means a model can be easely rescaled for different purposes, i.e. the courier body is certainly scaled up for the trader, but you can't see this difference in FFED3D's export (scaling in FE2 is still a riddle to me, you got at least two values to scale a model in the objects section, but i found none of them is compliant to the next model ???, which brought up the idea that there must by something like a scaling table by which the models got scaled finally and the "values" are adresses or point to the value in the table directly).

keeping FE2/FFE ship specs was always a problem, personally i used them for all Frontier conversions, but i know also that they don't match to how it was planned, if you look at the early releases of pioneer and the contained "templates". (in my actual files they are still kept as alternative ship devs).

another reason why i would like to see Frontier ships get divided from Pioneer ships.

i guess, keeping the specs in a comparable range is up to the devs.

but please keep as much of the original idea a modeler had. i mean, if one gives a ship a certain mass/capacity relation or a special thrust setup, he usually had a idea behind that and that's a part of the model to, imo.

There are plenty of reasons why thats just not always possible. All ships were re-adjusted a few months ago to ensure some kind of balance in combat, its why so many smaller ones were nerfed, I mean check out the Talon(one of mine) its nerfed so much to be practically useless, but what can you do? I could moan but that solves nothing, theres a reason for the nerfing, and its so that you can hit the thing with a weapon 😉

He's likely referring to myself or JohnJ, since we are the ony ones who have worked on this ship, IIRC your model/version is not included.

I couldn't disagree more with the sentiment about it being the worst ship in the game, its just no longer the best one anymore.

@Coolhand, I wonder if you realise that to contribute to a project it helps to get down from that big white horse, we just cant see or hear you up there... 😉

I dont mean to insult you Im only haveing a joke, believe me when I say we would very much like to have some of your pother ships included, that cobra there Ive seen it before on your site and wondered why it was never contributed.....

Here are some guidelines that you can follow to ensure that your models are included:

https://github.com/pioneerspacesim/pion ... Guidelines

The most important information is up the top of that discussion.

hey, that's not quite fair from my pov,

to me he never was upon a "big white horse", he IS a brillant modeler imo (many will agree) and he never was to eager not to share his knowledge with us (as i remember).

looking up is always better then looking down (you get a headake 😆 ).

after all, to me it doesn't matters how good or experienced one is, i like to see all of them.

Not fair? Its a jibe and totally just in my opinion.

Like Robn said the only way to have your voice heard is to participate.

If your not invloved than theres no-one there to push your ideas forward... Everyone has their own goals.

Im not disputing that, never. Now the problem is that many artists expect the devs to bend over bnackwards on command to implement ideas. Thats not how things work outside of a paid working relationship.

Edit// just to clarify this point: "he IS a brillant modeler"

I would go further and say that infact he is among the best that I know of... if not the best. I am not disputing skill here as clearly there is a lot on offer.

of course a model posted here is no warranty to be placed in the release.

it never was ment that way, i presented here new stuff even to get some critics before any was included into the game (in what way ever).

it's understood that after the dev team had been grown everything has changed a bit and i guess starting a issue is a acceptable alternative to a full participation via github.

[/hr]

even lumpy "wing commander" had a cockpit view !

I'm actually one of the few devs here that would love, did I say that loud enough.. LOVE in-ship interaction and cockpit views. I would spend time implementing such a thing, it just requires a lot of thought since I'm not a professional coder I find things that much harder 😉

The only way of implementing cockpits right now that I have in my head, is a 2d overlay with regions to be clicked and changed on click, very similar to what we have now but using an actual cockpit graphic like in Xplane or Orbiter.

But a full interactive 3d cockpit I wouldn't know where to begin... But that doesnt mean its not wanted at all 🙂

Well lets go then! 😀 We'll need:

1) detailed 3D model - nothing scripted, just a boring, but textured model of a generic cockpit, something with windows up/left/right & forward.

2) camera that is located where the "forward" view currently is.

3) place model centred at ForwardView location.

4) probably best to render it first, need to play with depth settings I bet, maybe disable testing/writing, and shuffle it around to correct position.

5) need to control, keypress + mouse look(?), and constrain the camera so it can't look "too far" in any direction.

6) ???

7) Profit!

Best to try this sort of approach out on something with a bubble style cockpit.

Anyone got any suggestions?

Other than: "Andy you're an idiot why haven't you made this a separate thread?" 😮

andy

Cool.

The bit that I have no idea about is how to actually pick up clicks on a region of the 3d object and animate that region on click, like pressing a button down or flicking a switch.

Edit// Like for a 2d overlay you would likely use the position on the screen, but with a 3d cockpit when the camera moves, its posistion changes...

Yeah agreed, that would seem to give a nice open view of the scene. Although I woulnd't really know until we try it for real 🙂

@Coolhand, You've obviously been through this with the Ravenstar for Orbiter, although perhaps that was different as Orbiter already has the framework in-place for 3d cockpits.. So any thoughts on requirements?

You can do a ray cast into the scene and see what you hit, but I prefer something a little different.

You generate a ray just like we would for a ray cast - project the screen space click into 3d and get the direction from camera pos to that position and normalise it. Then get normalised vectors to each element in the cockpit, find the nearest dot product between the object direction vectors and the click vector. Then test it for some threshold value.

This works nicely because if the dot product is 1.0 then it's pointing directly at it, 0.0 and it's pointing at right angles, -1.0 and it's pointing exactly away from it 🙂 Set the threshold at something like 0.9 and it'll always pick something that's within a little cone along the direction you're pointing. If you happen to have multiple things under the mouse that's fine because it will always pick the one that the mouse is closest too visually regardless of depth/distance since everything is a normalised direction.

No complicated scene traversal, bounding volume heirarchy tests etc. Just a few dot products, a min test and an if-else. You can probably optimise some of those away too if you're feeling fanatical 😆

First time I saw this in use my hand flung itself to my forehead with a meaty slapping sound! It's so obvious that I immediately looked back at all my old code and cringed 😆

You can go the other way too - run through a list of hot points on the current cockpit model in world space, project them back to the screen and chuck the x,y for each into a list. Then on mouse click, run through that list and match to the appropriate point. This also makes it easier in some ways to integrate with the UI/input layer.

There's also precedent - we do this in WorldView for body labels. See UpdateProjectedObjects() and PickBody().

Yes! Also a good idea! Especially if we already have a working example.

3D clickable cockpits? HOLY FRAK! 😯 That would be awesome beyond belief!

@ potsmoke66, Thanks! I've got to get to that station, even though it's back there in alpha 15. Pioneer sure is a moving target, isn't it? 😆

I'm glad you said you welcome contributions from people of different skill levels, because I want to share what I've been working on, humble though it may be. It's an upgrade (or possibly a defacement) of Philbywhizz's pad stations. 🙂

[attachment=979:MexicoCity01.jpg]

[attachment=980:MexicoCity02.jpg]

[attachment=981:MexicoCity03.jpg]

...and because I can only do 3 attachments per post, here's the actual file. Instructions are included.

[attachment=982:spacestations 12.zip]

@potsmoke66, Ok, that worked. Actually what I did was move the models/spacestations.lua over the stations/spacestations.lua that I modified and overwrote it. I suspect the two files are not quite the same because the station had the old crappy green interior that I stuck in there. As for the outside, its absolutely beautiful. It's darker, but not too dark. I know how difficult it is to put textures on those shapes, and you've done a fantastic job. I have a major bit of constructive criticism and some minor bits, however.

Major bit: The window textures, while nice, are in the wrong places. This station rotates to provide artificial gravity. Your windows are on the floor and ceiling, and are too big for the scale of the station.

Minor bits: I like the illuminated font for the station name, but I think aesthetically it's too large for the place it's on, and besides, there may be stations with longer names that wouldn't fit. The radar dish looks great, but looks off center in that location. I think it would be cool to have two of them on the outer ring at the end of each arm. Oh, and I think the nav lights are flashing a bit too fast. Now, aren't you glad you helped me get there? 😆

In summary, I like it a lot but please fix those windows! 😀

i was aware of that, 1st issue is somewhat mipmap bound, if i make smaller windows they vanish completely because of mip-mapping even on highest detail level. that's a problem i (anybody) have with all buildings (compare even my new cylindrical building, the windows have to be sized up, they vanish much to early).

2nd, artificial gravity, i know it will be wrong (and you was clever enough to recognize that 😉 ). but, i haven't had any good idea to solve that, except a giant texture that will cover the whole wheel from top view, common texture or glow-map.

edit: wrong, a mapping only for the inside facing part would be enough (centrifugal force to the outside), but the torus had to be changed into a "lathe" perhaps, further sections of a tube/cylinder never match sections of a torus (one starts on the corner of the division the other on the center of the division)

a soulution would be a complete rebuild of the torus

[attachment=983:torus_1.jpg]

the radar, was planned to be off center (as long that it's rotational axis is centered). well there are some disabled calls for a (updated) building of mine, i disabled to avoid complications and i thought perhaps some wouldn't like that, looks a bit weird).

could be now that the nav-lights are really to fast, still i'm not able to run pioneer on the macbook* and the wrapper is far to slow (1-2 fps), i'm simply not able to tell if they are fast or slow (it's guesswork).

maybe the green & red pos-lights are better left as they was before. it's more a experimental use here, to show that you can use a sine to control a

flashing light. if the frequency is to slow it will show off a quite to long fade-in, fade-out. while on higher freq. it looks better then a immidiate change (rectangular signal), imo.

[/hr]

*

"Error: Vorbis could not open data/sounds/Interface/OK.ogg"

somebody's got any idea, do i miss something perhaps?

I can't quite follow you there... The wheel is in segments, it is no problem to map those segments to a texture tile (maybe two or three, so it doesn't get too repetitive), but there's no reason to make a whole texture for the entire wheel.

Actually the wheel is a ring in the original (I used two overlapping rings to reduce texture smearing) and it's made of lathes in potsmoke's version. In both cases the wheel is made of big ring-shaped pieces. The original wheel is low-res enough to be remade with segments, but potsmoke's has so many integer steps that it appears perfectly round (with no decrease in performance on my old pc, btw). What about putting a ring or lathe inside the main ring with a glowing material and generic wall texture , and cutout windows in the hull? This might give the illusion of 3D rooms inside the station.

Here's a couple of pics for those who haven't seen it.

[attachment=984:Gatesp6601.jpg]

[attachment=985:Gatesp6602.jpg]

All of the spacestations are scripted objects aren't they?

As in they're not modelled they're defined only in "spacestations.lua" which creates quads, strips, lathe etc.

So basically, the model is defined as a function and the mesh gets procedurally generated in increasing detail...

I don't know how neccesary that really is, and one important question would be wheather that mesh is created using CPU or GPU cycles.

For an object this big, and considering you'll have only one on the screen at a time, it would IMHO be better to make a mesh with some 10'000 to 15'000 faces. Only few will know the difference. If the current mesh is CPU produced, this will also run FASTER, because handling such a model is doable without trouble by almost any GPU nowadays (except some ancient laptops, maybe).

If you really want to stick with procedural mesh generation, You have to do procedural UV mapping too, there's just no way around that.

@UncleBob,

That's a long and detailed argument you'll end up having with people. Though for what it's worth I agree.

However it's only constructed at startup, I think. I'll try to check now.

EDIT - Can't be certain because I don't know what the Lua script is actually doing _but_ it looks like it's only created once.

I think I confused a few thing. From Marcel's post, I gathered that the mesh is modified while running (similiar to a mipmap) to make it more detailed. After reading you post and re-reading Marcel's post, it seems that I was wrong about that, and that there are instead two versions of the creation algorithm around, with one adding much more tesalation than the other. The model gets created at startup, and doesn't get modified anymore afterwards.

In that case, there's absolutely no difference in performance wheather we create the geometry by algorithm or by hand (i.e. modeling software), since the finished mesh is dumped into memory either way. In that case I would strongly advise to make a nice model with a nice texture map.

The only reasons there could be for generating a station procedurally is a) making every station look slightly different and b) adding more detail to the mesh as you aproach. Both mean runtime modification, and can be worthwhile if done well, but I really don't see the sense in creating a static mesh by algorithm. Humans usually do that a lot better.

AFAIK Tom originally did this as a homage to the old games 🙂

One of their advantages is how simple it is to add extra detail levels or lower detail levels for LOD, you can do this normally too but it requires more work, you'd have to manually make each LOD. But like you said the end result is almost guaranteed to be better using an .obj and nice texture mapping.

I suppose its quite easy to create morphing geometry with them too, although that would be far better done on the GPU, and to hell with the collision mesh hehe 😉

hm...

pioneers native scripted geometry will be always better for performance.

i can't tell you why, but i have made enough models to compare between (i.e. cty3k exists as sripted geometry as well as made from objects), that i can tell that exactly from experience (and i fear that everything gets turned upside down, just that some rectify themselfes and some theory**).

one reason could be that i can only project textures, there is no unfolding and no resulting per face texturing.

if you arrange the geometry by texture and projection values, you gain some additional speed, imo.

btw, the original "wheel" had fixed divisions, while i used LOD dynamic divisions for all parts of the "big crappy".

and if you still don't believe, try to experiment rather to theorize.

to me it counts only what FPS i got afterwards, where it may come from i don't mind (...to much, could be interesting to theorize about that, but didn't changes the result).

some believe in theory, i believe in facts (results). i'm a construction worker, it doesn't matters what a paper says, but it matters much if it works out and lasts.

or to tell in other words, i construct a pipeline without a balance and it's more straight as the one which is been made using a balance. in the end it's measured by the eye and not by a little air bubble.

if i stamp decals and emboss them i could calculate the thickness of the material and set the machine up with this value, it never matches. i HAVE to tweak it with the eye (in the best case you can't see where it was embossed if the decal gets peeled off).

of course we work here only with virtual things, but still to me the result is what counts.

you can use also a texture on lowest lod, but don't be surprised if you get a weak performance....

you can run with your head even through a wall, it will hurt i promise.... (i know that from experience too 😆 )

[/hr]

if people are able to manipulate negatives of x-ray pictures from a uranium pellet, there are willing to manipulate anything, just to rectify something....