OOOooooOOOO 😯 This is looking really great! 😀 Imagine seeing that coming up on the night side of a planet as your coming into land in a heavily populated starport. Brilliant!

Wow, that's cool 😀

We need a system to activate lights on night time tough...

Also, night time lighting is pretty much glitched:

there is no shadow system, so at night the sun light just passes trough the planet and ultimately casts light on buildings and ships that are supposed to be darkened by the night.

Yeah! Thanks to both of you. I imagine Batman would feel right at home in there! 😈 (nearest match to Batman)

I agree on the need for a proper shadow system. I don't recall it being listed on GitHub. It ought to be on the to do list. Maybe I'll Git to it, maybe I won't. 😉

Wow that's looking goood. Are the lights visible during the day? It really would be good if the buildings would cast shadows too, although it would no doubt effect performance..

Wow! I go away for a little while and it's all change 🙂

These buildings look great and they really make the cities great looking places.

Awesome work Vlastan and everyone.

Amazing!

Pioneer will someday be THE space sim I always wanted 🙂 (Today it is veery close 😉 )

dynamic lighting and shadow system for buildings and in gneeral would be a good addition we are graphics heavy on this project anyway

No, we're not.

a new programmer may come along with dynamic lighting and shadowing work over time anyway good work so far

Dynamic lightning is a good thing ever, but some basic black surface "fake shadow" effect should be a beginning, that basic shadowing changes things dramatically and offers a lot o sense of distance and looks good.

I am thinking about the basic shadowing over terrain from Orbiter Space sim, for example. The planet is a plain sphere but the black shape shadow over terrain do a great job.

would aid a lot with low level flight distance measuring, with the shape of the ship over the terrain and the cities would look more "solid" over the surface.

Greetings

havn't read it all...

dan, not so long ago i thought about that idea of large planet filling cities, someone you?, many else brought up already some time ago.

well a rendering to the horizon is not impossible as we see, but useless.

but couldn't a patch be repeated, like they do in the movies? (like a kaleidoskope).

you won't notice the difference from a certain range on.

wel another idea that might help,

pioneer is generous with polygons, really, textures lower performance much more.

just to remember.

another fact, per face textured meshes are more intense rather projections like you do on scripted geometry.

one advantage is that you can group objects by texture projection and that keeps it already lower i guess.

that brings up a question again, would be nice to "override" the per face uv with a projection sometimes for wavefront objects to. btw, i checked the source and was surprised that a mesh without uv should get loaded, but i said should i kow from the very start and still (i checked, alpha11 of course), the game terminates when a mesh has no uv.

no big problem, i was only surprised when i saw the case handling for a mesh without uv.

and yes keep the lowest lod extremely simple when used only as collision mesh.

it's not needed to use all levels allways and i know it's a bit boring to do if you make models with a cad program, while

the dynamic scripted stuff hasn't to be modeled twice.

but on the other hand, buildings like those new ones have a "simple" (not ment as critics) shape and can have easely a second very low lod from a not to far distance.

i'm not shure are they textured at all? they look a bit like not, but i couldn't tell proper from far.

well at least like i said that would help much to improve performance.

i must say, all i created in the past time is completely contrairy to that and i really used it up to the limit, no wonder my gfx card has lost it's life 😆

oh, limit, again i reached some modules limit, at least after finishing the starports i couldn't ran the game no more unless i disabled some other models 😮

well i guess the animation of coolhands viper has cost to much sub-models 😆

it's not true in fact if one uses a bit much then the pilots i changed (again), but i found out that a static model latter animated keeps the framerate high. any dynamic handling (dynamic textures or transformation of the mesh) of a wavefront object is bad. stumbled over that while checking the "terra" ship.

low framerate? why almost no textures only materials, shouldn't be that way...

so i visited the pilots and yes a lot of dynamic selected meshes and textures, very bad.

after the cleanup you won't feel the pilot and it's relly no big difference now if i use one or 5 pilots in a ship.

but therefore i had to use ten times more submodels...

but still this is the proper way and i was already on the way to revisit all models and fix any dynamic wavefront .obj use.

i'm pretty shure this helps much (you really should see the difference of the new pilot models).

really i can use a dynamic moved texture on a scripted geometry and it's far less process intense rather a simple rotation of a .obj mesh as long as it's not a model.

Had a bit of trouble reading this and figuring out what you meant but a couple of things stood out.

For the ships a texture should only make a small difference if it never changes, I think the problem with some of our models is that they're made up of a many small components that are all separately textured and have different materials. That means that we make lots of state changes in many parts of the rendering process.

A while ago you posted the YT-1300 (Millenium Falcon) model for us to play with which is a good example of what I'm thinking.

It has many little meshes and a single part of that mesh with transparent (or should be) cockpit with Han and Chewie in it... really cool little model, but there's no reason for all of those meshes to be separate except that they use different textures.

Instead all of the textures should be combined into a texture sheet/atlas (terminology almost interchangeable) then the many smaller meshes can be welded into a single mesh and drawn with a single mesh and single texture which is much faster for the CPU & GPU.

The only part you should keep separate is the transparent section so that it can be rendered after the opaque geometry.

i'm not shure if a single map will be better, e.g. millfalc. it's made "old school" since it's a rather old game it's from (SW-XWA).

i left the texturing as it was made by "darksabre", very nice to do for pioneer i hadn't to remap the model.

the version i started for ffed3d is still in work and give me some trouble remapping all the little parts to one sheet like it's needed for ffed3d, especially because some parts have their uv spread over various repetitions of the texture.

another reason is that i often use a simple basic texture, it can be used repeatingly and gives often good results with small textures (128*128), i.e. a concrete material.

really i'm not shure about, but looking at older games when we had less powerful computers can help to understand why certain things has be done in a certain way, save power.

the cockpit of the millfalc was never ment to be seen with the whole model. it's a extra model for a cockpit view.

but pioneer has far more then enough capacity to handle it in one model (in fact, han would have textured eyeballs and a seperate teeth model, from which you would see i don't know, amazing, i only miss the dirt under his finger nails).

personally i think handling many little seperate textured is easier to handle, guess of just the simple situation if i use han and chewie only down to a certain lod, the full texture map would still be needed for the remaining parts.

apart from that i have no or less unused black texture sections, so that imo, i use less but get more.

per face textured i would say it's the same, one big sheet or many snippets, in both cases every single faces uv had to be processed.

problem with generated texture maps, pioneer can't handle texture islands on a mesh with unified vertices.

that means any texture seam you have must have unique or splittet vertices, else the mesh gets smeared over the texture.

somehow i guess it's because .obj files have no additional texture verts to handle texture islands, even if it should be possible without (blender shows no problems and neither most 3d viewers).

as a bad example take my conversion of sol commands ghoul fighter i had to split edges all over the model just because of the many texture islands.

really try some tests, after all projection is far easier to handle and in the best case you can load a texture and it's projection values once for many meshes. i felt that's a real big difference.

but projection is very limited i know, i can't unfold a mesh, but exactly this is process intense and if i'm not wrong per face texturing at all.

if i look at good ole' millfalc (and the other ships of XWA family), they look to me like projected textures. i mean each snippet is textured from a certain angle, looks like no per face texturing in the original file (i guess i have to snoop the file structure of the original models once, could be some other model convention, such as materials get defined only by texture and projection is always 1:1 (no matter how big the part, it fills always the hole texture), like VRML how it was used for "sports car gt"). but if you convert the original to .3ds it will have of course a per face texturing.

also the spreading of uv over many areas, can come from such, if i use projection values the mesh won't be placed always in the first repetition of the texture, it depends on how you position the texture (for pioneer this would be negative values from 0 to -1, i.e. texture('tex.png',v(-.5,-.5,0),v(any),v(any)) but it doesn't matter the result is the same and you see this only if you convert the geometry to a solid mesh which will be per face textured then.

really i didn't think this lowers performance, but it's far more complicated to do, i can't just press a button and get a map from.

"sports car", was a good teacher for me, 4 lod's and used any trick to make the game run smooth back in '98.

well i've read somwhere here about object shadows...

sports cars solution, a alpha projection, something like a inverted glow, a simple texture which is projected on the street likewise the lights of the cars or the wet reflection effect, simple solution, good result.

It is indeed old school 🙂

As an example of what I was thinking, there's a script for Blender called "Consolidate into one image" which is supposed to do what I'm trying to describe.

http://wiki.blender.org/index.php/Extensions:2.4/Py/Scripts/Image/Image_Auto_Layout - it is supposed to take all of the images used by a model built of separate components and arrange that into a single packed texture, then it remaps the models UVs to use this texture.

You're correct that it means you will need to duplicate vertices along edges that don't match but this is not very important and the GPU will easily tear through the few extra vertices much faster than it will handle switching a texture even once.

The older way of doing it with many small textures, and many small meshes suited software rasterisers, but they're anathema to modern graphics cards which prefer to work on big chunks of geometry and rarely changing textures or other graphics state. This is why modern graphics programmers talk so much about batching render state changes, sorting things by the textures they use because they want to provide the graphics system with the largest chunk of data they can, and when they must change what they're drawing they want the change to be as small as possible.

Andy

@ Potsmoke66 and everyone else

I just wanted to say that sometimes I come across as a bit adversarial and sharp but I don't mean to.

The current work that everyone has done on the modelling is fantastic, and everything that I'm saying now is just to try and help us find a way of giving you guys more polygons and textures to work with... which is not something you'll usually hear from a programmer during game development! 😀

We're usually the ones demanding that you use smaller textures and less triangle, but you guys seem to have taken that to heart when really you could be using an order of magnitude more!

Andy

HI to all, i am happy to see my models officially included in the latest alpha and i am eager to continue working on this project.

However, i had some troubles with my computer (my ram is damaged) and i'am now working to recover my system.

I am now planning a new set of building models (outdoors, with domes for non breathable environments) by the release of alpha 16.

Stay tuned 😀

Awesome, I look forward to seeing them!

if anything is GOOD then it's constructive critics and comprehensive explanations 😉

[/hr]

i'm satisfied to see that i'm not the only one with a "broken machine" 🙂

well, i have no idea how far it's getting with a seperation of buildings/building sets

in despite of that, i have made some thoughts,

in some sort it would be cool if we would have a little bit of homogeneity.

let's assume we would have different architecture even for the variations of political systems, wouldn't it be nice to keep this homogeneity by leaving a certain political system to a certain modeler?

i know, perhaps a problem when more modelers move in or anyways later on, but probably such could be splitted then randomly (a system uses allways the same modelers architecture).

different guessing,

well this (a system uses allways the same modelers architecture) could be also a simple way to divide them at all disregarding any other.

i will put this request on the issue list, as i think it's worth.

@potsmoke

When you say homogeneity do you mean like the similarity in styles between say, Swiss Alpine village and Traditional Japanese homes/shrines? I.e. they all vary a bit between individual buildings but you can always tell where they're from?

Andy

@andy

i guess that describes it well.

yes, why not?

after all

"a system uses allways the same modelers architecture regardless of other tags"

i feel most comfortable with,

because

it would leave the possibility for the modeler to create buildings for whatever condition, but keeps this "homogeneity" on a certain system/planet.

it's not a must just a idea, well i guess it will look a bit strange if you mix already only mine and vlastans buildings

btw, what about allegiance for ships? i guess everybodys feels that not all ships should be available everywhere.

a courier belongs to imperial systems only i.e.

perhaps a "low-level" sytem offers only low level ships?

well if you ask me, a courier should be sold only to imperial pilots, but we're not that far now.

such or similar would be cool and i can i.e. determine better what emblem a ship wears (or let get determined by a player profile).

This is part of where I'm going with buildings: tags and attributes to declare features or relationships. Once we have a clear concept of factions, then an affiliation of some sort can be provided by models. What it does exactly is unknown right now.

What about this?

Don't leave us hanging!

apart from "looking cool" there is a static problem, this will last even in xx century, physics never change.

i can model anything in 3d, even a a flying city like metropolis, but is that realistic? could such ever be made? (a little at least).

i don't like "in 40th century..."

because i don't think so.

certain things can never be solved, and even if some crazy people believe that antigravity is possible and that some might have invented it already in the '40s, makes me laugh.

Yeah, those ships are also work in progress 😉

I hope to get back working as soon as possible

Cool ships. But they look awfully small - no room for cargo and fuel. The first one could be a fighter and replace the Eagle. The second could be a shuttle travelling between orbital stations. The third one is more like a car - we could have those flying around cities in many colour variations.