Jump to content


- - - - -

looking for cockpit/gauges photos, all cars '65-'69


  • Please log in to reply
95 replies to this topic

#21 sky

sky

    ultra highres junkie & 917 addict

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,550 posts
  • Gender:Male
  • Location:the last haven for petrolheads
  • Interests:travel, music, racing, vintage cars, model cars
  • Sim interest:GPL

Posted Jun 01 2009 - 07:25 AM

only a minor update... i have been tinkering with the ferrari's .3do over the past week. see if i could change a few things without gpl refusing to load anymore or some such. well turns out i could. even managed to get some retexturing done. my focus, as hinted at above, was the windscreen. now here i ran into something peculiar. the way i imagined the windscreen to be is like a big rounded U with the bottom center part right in front of you. well think again. in this model it is actually 3 straight sides going of in almost 90° angles. that's why the windscreen is actually inside the car in front of the dashboard (meaning nearer to you than the dash). so that made things a bit odd. i played around with that a bit, got the top edges to be pretty smooth, but haven't been to revisit that particular texture. not sure if i want to do that or just redo the current texture (and alpha) in such a way as to get the same effect of a nice and smoothly rounded windscreen. the latter version not doing anything to performance as only the texture changes. the other one would be additional 10 polies total ;).

anyway, so as i'm only doing (re)texture(ing) work at weekends, i've been fiddling with what i had previously claimed to be pretty much final :P. turns out it wasn't. far from it. so i redid the entire cockpit, moved the gauges around to where my reference pics would have them, added a few bits'n pieces like additional switches, warning lights and labels and am closer to being done with that part. note, closer, not done... the fire extinguinsher switch to the right is just temporary (not being helped by the fact that the cockpit textures are severely stretched on the outside edges- just look at the leftmost switch and how it appears in the texture - interesting, yes very much so. that fire switch is very likely going to be modelled in 3d, then rendered to a pic, then a simple template will be created based on that render, put in the car and will then be morphed and transformed until i feel it looks right. then the actual rendered pic will be distorted & transformed in a similar way, a few shadows will be added and then that's done (i should think).

oh yea, those needles haven't been readjusted in the .3do yet. i've done that to test if what i was doing actual makes sense, and yes it does. lol. but note the rpm - it maxes out at 10k whereas the car actually does close to 12k there - so i need to fix the rotation value in the .exe as well. i'm not sure if i would want to do that. maybe someone could help me out with a patch for gem? that would be the "easiest" way - depending on how hard rotating one such needle would be. otherwise there's still the backup of the old gauge scale ;) i'd prefer the real one though


regarding the actual dash. i am aware that, as it is, it is quite dark(ish). i will brighten it somewhat - though that's a matter of taste and screen adjusting mostly. i've got a crt and a tft next to each other. the crt shows the cockpit considerably brighter, although it is set up very dark - whatever. also check that there is two versions of the dashboard cloth / leather. one is a rather dark leatheresque thing and the other is something, well i don't know the actual name for - some fuzzy velvetish stuff with fluffy threads (lol). according to my references the latter is the actual cloth, just varying from rather light to almost black over the course of the season. i guess they didn't bother cleaning off the oil, dust and grime after every race :D.
onto the steering wheel. these are now scaled down. came out okay. it's just that for some reason, when i feed winmip2 a 16bit texture it bands some colours. i don't know why, especially since i resample all my textures down to 256c then up the colour resolution to 24bit rgb (so those pixels should still only have 256 colours, right?) before i import them into winmip2. well, whatever, right now i have got about 8 variations of the steering wheel (from very light to dark and scratched - what you see in the brands shot) - there's going to be a few more, as right now the actual wheel part is way to dark - notice the dark band? that's what i meant above.

next up i will dive into making the padded sidewall. does anyone have a nice closeup shot of that pattern? head-on shot of the headrest would be awesome (same pattern and it's a flat surface).


well that's it for now, here are a few screenshots.
note regarding mip settings - i saved these as 0 mips, with mips=1 or anything else the lettering in the gauges gets blurred :( so mips >0 is not an option for me, but anyone can change that to his or her liking with winmip later on, i guess.

Attached Files


Edited by sky, Jun 01 2009 - 07:35 AM.


#22 sky

sky

    ultra highres junkie & 917 addict

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,550 posts
  • Gender:Male
  • Location:the last haven for petrolheads
  • Interests:travel, music, racing, vintage cars, model cars
  • Sim interest:GPL

Posted Jun 04 2009 - 02:14 PM

ok just a bit of quick info.
while tinkering with the ferrari.3do i found something that may or may not be of interest to some of you. if you want to change the rotation of the needles for any of the gauges, you need to do a bit of math and/or maybe any free 3d modeller. NO need to modify the .exe!!! i used 3ds max for my idea, but hey, it's a leftover from a former job. zmodeller should do just fine. your 3d app comes into it in such a way as to conveniently figure out how to rotate and what values to expect. that is if you need to rotate the dials by some rather arbitrary angle. for my example i chose 90° - which just so happened to be the exact angle for the rpm counter to line up with the markings in the my new done gauge :D

first up, i opened the ferrari.3do in the gpleditor. went into the MIRP / PRIM(itives?) > 3do tree root > ptach (rpm counter). the first entry [3c] is the node defining the position in the car / cockpit. so if you want to mess up your gauges very fast, move this one around. it defines the rotation center (1)  of the needle. move it left / right, up / down, forward / backward and you'll see an immediate effect ingame.
anyway. so underneath that node are two more entries, bottom and top "half" of the rpm needle. i say "half" as they are not really halves, just the parts of of the actual needle. the dot in the middle is a piece of background graphics...
so you open each of those two polies (1) and take not of the numbered vertices (118-121 for bottom half, 122-135 for upper half). with these coordinates you can re-create 2 similar polygons in your 3d editor of choice. select those two polygons in your editor, fix the center of rotation, see above, and rotate the dial by whatever angle you want. then write down the coordinates of those points again (vertice 118: x,y,z, ...). i chose 0,0,0 as the center of rotation just for ease of use. was perfect in this case. maybe it always is - didn't really test much :D

in my case, i chose to rotate by 90° degrees which here is an easy affair. just swap the y and z coordinate for any vertice. say vertice 118 was x: 0, y: 22, z: 33  -> x: 0, y: 33, z:22. to keep the same drawing pattern (of the polygon) as before, i changed the order as well - 118 became 121, 119 became 120, 120 became 120 became 119, 121 became 118 (see screenshot of editor if it confuses you :D - i know it sounds :S)

then go back to the gpl editor, goto SZYX and find the vertices you need. click them and edit them accordingly. as i was the lazy bastard i just copied the original entries of those vertices into a textfile (2), swapped them around in there and copy pasted them back straight into the editor (3).

so then you end up with the needle (in my case) rotated by 90°. no editing of the .exe file necessary.

the only downside to all of this is that in my case the markings of the rev counter start at 2000 rpm. gpl without modification doesn't move the needle until it is at 3000rpm (for this car anyway, can't say i checked any of the others). so the idle resting spot of the needle is at 3000 rpm - engine idling at 800ish rpm or not. i find that rather annoying, but heck, at least now the needle shows the correct values again once it is at 3000 rpm or above, oh weheeee.
i will finetune my other needles as well. i guess i finally need to install pribluda to see if the needles match the actual values... might be good, as i then might be able to see my speed too :)
oh and as i guesstimated by the stuff i found in the .3do of the ferrari, the oil temperature has a working needle as well. it's just not used in the '69 dashboard.



now if all of this doesn't make sense, just ask, i'll try to clarify. had a bit of booze before tinkering around :D - it works nonetheless :D

/coc* a) i'm somewhat more dyslexic tonight than usual B) the images are attached in a backward fashion c) something else

Attached Files


Edited by sky, Jun 04 2009 - 02:23 PM.


#23 MECH

MECH

    Double poly killer

  • Administrators
  • PipPipPipPipPipPipPipPipPipPip
  • 2,408 posts
  • Gender:Male
  • Location:Here ->
  • Interests:My Girlfriend
  • Sim interest:GPL

Posted Jun 04 2009 - 02:37 PM

I gather you rotated the polygon vertices to get the proper angle for the needle right?
That should be working as you already figured out  :)

The fixes in the exe are for the needle ranges as well iirc.
So if the needle has the same range this would work in your case.
If the min/max range of the needle is different then the exe patching is required.

Although for a larger range that might also be possible by moving the needle from the center point with help of a transparent piece :think: (requires a lot of fiddling or some calculation in excel  ;) )

Forget that the circle radius would extend as well :duh:

Edited by MECH, Jun 04 2009 - 02:39 PM.


#24 sky

sky

    ultra highres junkie & 917 addict

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,550 posts
  • Gender:Male
  • Location:the last haven for petrolheads
  • Interests:travel, music, racing, vintage cars, model cars
  • Sim interest:GPL

Posted Jun 28 2009 - 12:38 PM

View PostMECH, on Jun 4 2009, 10:37 PM, said:

I gather you rotated the polygon vertices to get the proper angle for the needle right?
That should be working as you already figured out  :)

The fixes in the exe are for the needle ranges as well iirc.
So if the needle has the same range this would work in your case.
If the min/max range of the needle is different then the exe patching is required.

Although for a larger range that might also be possible by moving the needle from the center point with help of a transparent piece :think: (requires a lot of fiddling or some calculation in excel  ;) )

Forget that the circle radius would extend as well :duh:

ah yes, i did actually rotate the vertices. that's where the 3dsmax majic comes in. did some more of that today. finally getting back to getting some work done and not trying to beat the ring. well i did, but failed, so never mind.

ok so i now fixed the needles in size and length to what i want, added a textured needle for the rev counter and did some more tinkering around with tiny bits and pieces.

so i'm editing the ferrari.3do - all is well until i try to remove a textured polygon. i tried "replace node -> remove" but that crashed gpl. then i tried to remove the vertices from a polygon to keep the poly from showing up (much smart, eh?  :idunno:) but that keeps crashing gpl as well. wtf?
on a positive note, i managed to add a new texture to the .3do and that didn't crash it, although i had to replace some otherwise flatshaded polies. so why wouldn't it let me remove say two of 5 polies of one group??? i end up with 3 textured polies and two "empty nodes" - just as it should be. but on saving it tells me section length changed to whatever and then gpl crashes. well, when i say crashes i mean it refuses to load a track as the car is fubar according to gpl.
:(

see attached screenshot. whenever and however i try to remove that selected polygon, gpl flips me the bird afterwards. what am i missing?
i tried right click -> remove -> remove node. that ends with 'empty node -1' and fail
i tried right click -> cut node (without inserting a new there - that ends with 'empty node -1' and fail

i'm a bit stumped really. it must be possible to remove individual nodes without messing the entire file up

Attached Files



#25 MECH

MECH

    Double poly killer

  • Administrators
  • PipPipPipPipPipPipPipPipPipPip
  • 2,408 posts
  • Gender:Male
  • Location:Here ->
  • Interests:My Girlfriend
  • Sim interest:GPL

Posted Jun 28 2009 - 01:27 PM

Mmmh, i'm afraid you got caught by the 'unfinished GPLTrackeditor' bug.
Not all menu options in GPLTrackeditor work like they should.

Basic rule is if you want to change anything in a 3do use the insert - replace node then select the type node you want. There's a catch though if what you replace uses more or less bytes then what you are changing you'll see a notification that the number of bytes is changed (as you noticed already) The most right value is the value it was and the left value is what it has become, obvious right? :rolleyes:
If the amount of bytes has decreased then you have a problem. GPLTrackeditor doesn't delete the obsolete space in the tables so you need to correct this.  This can be done by hexediting (delete the number of bytes at the end of the file) or by a program 3docorrector (i prefer this coss' it ain't the first time i screwed up a car by hexediting  ;) )

Can't find it on SRMZ and RSC so will post this in a minute..(in the mean time you can read ahead)
Link: 3doCorrector


If what you replace uses more bytes then there's nothing to worry, it will probably work  :)

Should you need to add another branch on let's say a type 4 multinode with 2 branches it requires a different approach. The cut and paste node commands are functional so you can use these. I normally would cut the type 4 node and past it temporarily on an empty node(or leave it in the paste memory) Then use insert - replace to create a type 4 multinode with 3 branches and cut and paste the other 2 branches over to this new multinode. This would be the time i press save. Then cut the leftover multinode with the 2 branches and use 3docorrector to remove the spaces. Next i would start altering the 3rd new branch (or child if you please)

Some problems are easier to solve by cutting a node and leave the cut in memory. Then apply changes and paste the node in memory back into the new situation. It all depends in what you need to change.
I think it will become more obvious once you start playing around with it.

Hope this makes things a bit clearer but could easily make it more complicated  :D

P.S. Some type nodes don't like empty child nodes once created. Can't remember which atm i believe some positioners make a car.3do crash. Next should you add extra vertices to change a polygon better press save first. If you would try to center on a new vertice for a better view GPLTrackeditor would crash.
New created node have mostly an unknown adress like cccccccdddd. To be able to hexedit such a node it is necessary to save first and restart GPLTrackeditor (free's up the memory as well) Now it will display it's offset to the PRIM value (so the PRIM + offset will give you the exact location for a hexeditor)

Edited by MECH, Jun 28 2009 - 01:50 PM.


#26 MECH

MECH

    Double poly killer

  • Administrators
  • PipPipPipPipPipPipPipPipPipPip
  • 2,408 posts
  • Gender:Male
  • Location:Here ->
  • Interests:My Girlfriend
  • Sim interest:GPL

Posted Jun 28 2009 - 01:43 PM

Regarding your empty node remark:
If you want to remove a polygon just use the cut node and run 3docorrector.
An empty node isn't much trouble for GPL.

If you do want to have it gone you should cut the type 4 with the 5 childs.
Create a type 4 node with 3 childs and paste the cutout in the last child.
Then cut/paste the numbers 1 & 2 to the 1st two childs and cut the 3rd polygon and paste it back over the 3rd child overwriting the type 4 with the 5 childs.
Press save and if the size has become smaller run 3docorrector or delete the difference in bytes from the end of the file with the hexeditor  :hmm:

#27 sky

sky

    ultra highres junkie & 917 addict

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,550 posts
  • Gender:Male
  • Location:the last haven for petrolheads
  • Interests:travel, music, racing, vintage cars, model cars
  • Sim interest:GPL

Posted Jun 28 2009 - 01:47 PM

ah ok, that makes sense - well what you write makes sense, not the way the editor / file is built :D. now where have i seen this behaviour before?

regardless, so what it comes down to, basically, is that you can't really remove things from the .3do without a high probability of messing things up? ok guess that needs a change of tack on my behalf. really what i was trying to do here was take out the current windscreen of the car, 9 polies per half of it, so 18 total, and replace it with a simple plane made up of 3 polies per half. that would save 12 polies total - not the worlds biggest improvement but something. also i'm doing this to make it easier to texture. i guess i could keep 2-4 additional polies per half, but really i don't need them there.
what you are saying (i'm very much reducing your statement here) is that i should probably use those 'saved' polies for something else already in this view or somewhere else on the car in order for the total filesize to be either equal or slightly more than before?
that's a shame really, cause i think the filesizes and maybe structures as well could be considerably smaller and simpler if it weren't for dead and empty nodes as remnants of some modification or other. that being said, i don't know what influence this has on gpl as such, i mean having to deal with this patchwork of a .3do file ;)

anyway, now where do i spend the remaining few polygons? the obvious choice would be some poly-spendage on the front suspension, i guess. it looks a bit flat and simple.

#28 MECH

MECH

    Double poly killer

  • Administrators
  • PipPipPipPipPipPipPipPipPipPip
  • 2,408 posts
  • Gender:Male
  • Location:Here ->
  • Interests:My Girlfriend
  • Sim interest:GPL

Posted Jun 28 2009 - 02:11 PM

View Postsky, on Jun 28 2009, 09:47 PM, said:

regardless, so what it comes down to, basically, is that you can't really remove things from the .3do without a high probability of messing things up? ok guess that needs a change of tack on my behalf. really what i was trying to do here was take out the current windscreen of the car, 9 polies per half of it, so 18 total, and replace it with a simple plane made up of 3 polies per half. that would save 12 polies total - not the worlds biggest improvement but something. also i'm doing this to make it easier to texture. i guess i could keep 2-4 additional polies per half, but really i don't need them there.
Well yes and no  :P
You can remove the basic stuff like polygons from the bodywork etc..
The driver, steer etc.. will probably crash GPL (i mean not the polygons maybe but the other type nodes like positioners and handles etc..)
As long as you fill in the spaces after messing with the car.3do GPL will probably not complain.

View Postsky, on Jun 28 2009, 09:47 PM, said:

what you are saying (i'm very much reducing your statement here) is that i should probably use those 'saved' polies for something else already in this view or somewhere else on the car in order for the total filesize to be either equal or slightly more than before?
Nope, see my 2nd post above.
If you use 3docorrector you can cut away a lot of polygons you don't want.
You can even remove empty nodes if you like to tidy up. But this will probably not give much performance improvement. After all we are talking bytes here for an empty node, you'ld need to remove thousands of those to even notice a slight improvement. I think using bigger mips might give you way more problems then some tiny empty nodes  ;)

P.S. (nifty phrase huh) I can't check it right now but i thought the polygons for the windshield are divided by planes. By cutting away those polygons and replacing them with one big polygon you're bound to get into trouble. The planes are used in GPL to determine what polygon has to be drawn on which viewpoint.
By ignoring those planes you will get clipping..

#29 sky

sky

    ultra highres junkie & 917 addict

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,550 posts
  • Gender:Male
  • Location:the last haven for petrolheads
  • Interests:travel, music, racing, vintage cars, model cars
  • Sim interest:GPL

Posted Jun 29 2009 - 11:16 AM

View PostMECH, on Jun 28 2009, 10:11 PM, said:

Well yes and no  :P
You can remove the basic stuff like polygons from the bodywork etc..
The driver, steer etc.. will probably crash GPL (i mean not the polygons maybe but the other type nodes like positioners and handles etc..)
As long as you fill in the spaces after messing with the car.3do GPL will probably not complain.

tried that. using 3docorrector it works brill!!

[...]

View PostMECH, on Jun 28 2009, 10:11 PM, said:

Nope, see my 2nd post above.
If you use 3docorrector you can cut away a lot of polygons you don't want.
You can even remove empty nodes if you like to tidy up. But this will probably not give much performance improvement. After all we are talking bytes here for an empty node, you'ld need to remove thousands of those to even notice a slight improvement. I think using bigger mips might give you way more problems then some tiny empty nodes  ;)

hm hell yea, 3docorrector is a very handy tool. saved my hide with my experimentation. quite brilliant thing. why it doesn't remove the empty nodes altogether is a bit beyond, but maybe that's just a setting or switch you need to engage.

my reasoning behind cleaning up the tree and removing unnecessary or unused nodes was simply that seeing how gpl uses a tree-structure for objects to determin what is being drawn when and where it might be saving some computing time by simplyfiying the tree. the tree-structure isn't the most resource optimized way of going about this. and i do not expect to see any improvements in performance on my own machine, but maybe on slower rigs it might, idk.
and as i said regarding mips.. these pretty much depend on your graphics card - also the number of mips you used will make a difference to lower end cards. what i meant with depend on your graphics card is really that depending on your card they might make a difference - though with most current low-midend (midend, what kind of oxymoron is that?) range cards and upwards (at least 256mb theses days) these shouldn't be a problem.. on my now 3yr old x1900xt card(s) they don't make a difference whatsoever.

View PostMECH, on Jun 28 2009, 10:11 PM, said:

P.S. (nifty phrase huh) I can't check it right now but i thought the polygons for the windshield are divided by planes. By cutting away those polygons and replacing them with one big polygon you're bound to get into trouble. The planes are used in GPL to determine what polygon has to be drawn on which viewpoint.
By ignoring those planes you will get clipping..

actually you are right, of course :) it's the way the windscreen is built. by using 3 planes (left, front, right) and a windscreen built just like that from three planes, no curvature, connected via 90° angles. so i will probably have to rebuild the windscreen in a similar fashion to the way it has been before, but trying to minimize the distorsion caused by the perspective so that the U shape appears as one textured polygon. difficult to explain or envision without i seeing it. i'll post pics of what i mean once i'm done with that.

there's another area that totally annoys me in this regard, it's the joint between the dashboard and the inside sidepanels. the way they are textured annoys the pants off me, since you can't have a simple gradient running back to front as it will be severly distorted. just check out the screenshots or check out a car yourself. you will always see a seam running vertical somewhere left and right of the dashboard. thanks to the upper end of the cockpit wall being different heights the textures are zigzaggy distorted in the fez there no fun to redo... well enough of the ranting :D

#30 MECH

MECH

    Double poly killer

  • Administrators
  • PipPipPipPipPipPipPipPipPipPip
  • 2,408 posts
  • Gender:Male
  • Location:Here ->
  • Interests:My Girlfriend
  • Sim interest:GPL

Posted Jun 29 2009 - 12:18 PM

View Postsky, on Jun 29 2009, 07:16 PM, said:

there's another area that totally annoys me in this regard, it's the joint between the dashboard and the inside sidepanels. the way they are textured annoys the pants off me, since you can't have a simple gradient running back to front as it will be severly distorted. just check out the screenshots or check out a car yourself. you will always see a seam running vertical somewhere left and right of the dashboard. thanks to the upper end of the cockpit wall being different heights the textures are zigzaggy distorted in the fez there no fun to redo... well enough of the ranting :D

I've seen a simple solution for that in the sportscar mod using an external 3do call for a simple flat structure that is overlayed on the dashboard structure. By using transparency in the used mip you create a shade. You can get away with that because it is a single viewpoint and won't cause any clipping.
However i think that this was only used for shading the front dash and not the seems between sidepanels and dash.
But it might work the same in this case, just needs a bit fiddling to get it right  :dont_mention:

Why they just didn't use a single or more polygon('s) with a positioner isn't totally clear atm.
Probably because it doesn't involve hexediting, not sure though.

#31 sky

sky

    ultra highres junkie & 917 addict

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,550 posts
  • Gender:Male
  • Location:the last haven for petrolheads
  • Interests:travel, music, racing, vintage cars, model cars
  • Sim interest:GPL

Posted Jun 30 2009 - 03:24 PM

View PostMECH, on Jun 29 2009, 08:18 PM, said:

I've seen a simple solution for that in the sportscar mod using an external 3do call for a simple flat structure that is overlayed on the dashboard structure. By using transparency in the used mip you create a shade. You can get away with that because it is a single viewpoint and won't cause any clipping.
However i think that this was only used for shading the front dash and not the seems between sidepanels and dash.
But it might work the same in this case, just needs a bit fiddling to get it right  :dont_mention:

Why they just didn't use a single or more polygon('s) with a positioner isn't totally clear atm.
Probably because it doesn't involve hexediting, not sure though.

that's an interesting idea. i have been thinking about using a single big texture for everything at once, but then decided against it, as i think it wouldn't work with different fov settings. that's an area i have only tested once before. if you go to fov's of 85 and over it will look :S. but then if you do it like you said using a it just as an overlay for the areas where the two textures overlap.. that's brilliant indeed. i will have to test it. the fiddling is cool with me. i do that most of the time to get stuff right.

there's another thing there though. it might be a winmip issue or i'm doing something rather wrong. not sure yet. but whenever i try and use a 16c transparency map, my textures get colourbanded exporting them with winmip. this has happened with the steering wheel many a time and i don't know what i do wrong. i've tried resampling the textures down to 240 colours, then 16 colours for the transparency map, put them together via winmip and blast, colours banded again.  :confused:
this mostly happens with lots of colors in the same general colour area, like gray / black or green for trees.

i had even tried exporting an already existing texture to .bmp, then reimporting it to .mip and back to .bmp - looks different.. wt..? using winmip 2.17

anyway, i'm going to give the overlay idea a spin this weekend if i have the some time then

#32 MECH

MECH

    Double poly killer

  • Administrators
  • PipPipPipPipPipPipPipPipPipPip
  • 2,408 posts
  • Gender:Male
  • Location:Here ->
  • Interests:My Girlfriend
  • Sim interest:GPL

Posted Jul 01 2009 - 12:42 PM

View Postsky, on Jun 30 2009, 11:24 PM, said:

there's another thing there though. it might be a winmip issue or i'm doing something rather wrong. not sure yet. but whenever i try and use a 16c transparency map, my textures get colourbanded exporting them with winmip. this has happened with the steering wheel many a time and i don't know what i do wrong. i've tried resampling the textures down to 240 colours, then 16 colours for the transparency map, put them together via winmip and blast, colours banded again.  :confused:
this mostly happens with lots of colors in the same general colour area, like gray / black or green for trees.

i had even tried exporting an already existing texture to .bmp, then reimporting it to .mip and back to .bmp - looks different.. wt..? using winmip 2.17

anyway, i'm going to give the overlay idea a spin this weekend if i have the some time then

I normally save the _ti.bmp in photoshop as grey color values and set it to 8-bits. Once saving as bitmap i switch to 4-bits. Don't know why i can change that only there but it seems to work. The main bitmap i save as 24-bits color (winmip2 can't handle 32-bits atleast the version i have, v2vb16...2.17?? were did you get that one?) By reducing the darkness of the _ti i change the opacity of glass sections and change the shades of blue, red or green by using lighter colors for the main bitmap.

But i have to admit that the mip specs are a bit fuzzy to me. I never bothered much since i'm not doing much work on skins.

Btw, if you are resaving a mip make sure you delete the old one. Winmip seems to use the values for the replaced mip in the new one. This can set you of a bit if you don't know were it's coming from  ;)

#33 sky

sky

    ultra highres junkie & 917 addict

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,550 posts
  • Gender:Male
  • Location:the last haven for petrolheads
  • Interests:travel, music, racing, vintage cars, model cars
  • Sim interest:GPL

Posted Jul 01 2009 - 02:41 PM

View PostMECH, on Jul 1 2009, 08:42 PM, said:

I normally save the _ti.bmp in photoshop as grey color values and set it to 8-bits. Once saving as bitmap i switch to 4-bits. Don't know why i can change that only there but it seems to work. The main bitmap i save as 24-bits color (winmip2 can't handle 32-bits atleast the version i have, v2vb16...2.17?? were did you get that one?) By reducing the darkness of the _ti i change the opacity of glass sections and change the shades of blue, red or green by using lighter colors for the main bitmap.

But i have to admit that the mip specs are a bit fuzzy to me. I never bothered much since i'm not doing much work on skins.

Btw, if you are resaving a mip make sure you delete the old one. Winmip seems to use the values for the replaced mip in the new one. This can set you of a bit if you don't know were it's coming from  ;)


actually it's 2.16.6 according to the about window - misleading filename i had, i guess. where i got that, i don't really remember. i just trawled through my drives to find it.

anyway. my normal procedure - until i noticed the banding issue was to simply use rgb 24bits and save them as .bmp in photoshop. nowadays i do the following with every texture - even though it seems a great shame considering i go from 24 to 8bit.
1. do the texture until i'm more or less satisfied.
2. flatten the image
3. convert it to indexed colours 256c, perceptive master (?), noise
4. convert it back to rgb (shouldn't do jack to the actual colours)
5. save as 24bit .bmp
6. winmip it

for transparency maps i do 1 and 2, 5 and 6 as above
3. convert to indexed colours 16c, perceptive master(?), noise
4. convert back to rgb

i found that when i try to export 32bits (alpha and standard 8bit for r,g,B) - winmip will refuse to load the .bmp
i also found that converting the _ti to indexed colours and saving it as 8bit will also result in winmip refusing to load the .bmp.

that leaves me rather wanting. i mean, i should have 16bits available regarding colourspace, yet i keep ending up with 8bits and even less than that as shown by the banding. i mean, i don't know much about the .mip format, how it is structured and all. but looking at the filesize i'd hazard a guess that it is pretty much like a .raw (.bmp) image. one plane for each colour, one after each other (r,g,B) and probably a general header at the very beginning of the file including info on how many mips are stored, sizes of those mips and maybe offsets for each mip in the file (although that could be calculated by the size of the mip plus some info on the general type mit and a transparency palette or single color... it could be just a variant of .bmp or something like the .dds format for all i know.

that winmip saving over an old one issue is news to me, but unless i'm in a real hurry to try something out i usually create new filenames while saving in ps already.. which keeps ending up in a huge load of versions

it's a shame, as i think we're wasting a bit of the potential of the fileformat here. especially with petteri thinking we might be able to do the full monty, 32bit .mips

#34 MECH

MECH

    Double poly killer

  • Administrators
  • PipPipPipPipPipPipPipPipPipPip
  • 2,408 posts
  • Gender:Male
  • Location:Here ->
  • Interests:My Girlfriend
  • Sim interest:GPL

Posted Jul 02 2009 - 12:49 PM

View Postsky, on Jul 1 2009, 10:41 PM, said:

it's a shame, as i think we're wasting a bit of the potential of the fileformat here. especially with petteri thinking we might be able to do the full monty, 32bit .mips

Have a look in this forum for Papybmp iirc it can create mips type 7 (32-bits)
And if i'm not mistaken Nigel's v2 rasterizers can handle them too.

#35 sky

sky

    ultra highres junkie & 917 addict

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,550 posts
  • Gender:Male
  • Location:the last haven for petrolheads
  • Interests:travel, music, racing, vintage cars, model cars
  • Sim interest:GPL

Posted Jul 05 2009 - 06:38 AM

View PostMECH, on Jul 2 2009, 08:49 PM, said:

View Postsky, on Jul 1 2009, 10:41 PM, said:

it's a shame, as i think we're wasting a bit of the potential of the fileformat here. especially with petteri thinking we might be able to do the full monty, 32bit .mips

Have a look in this forum for Papybmp iirc it can create mips type 7 (32-bits)
And if i'm not mistaken Nigel's v2 rasterizers can handle them too.

oih wee, i found it, but for some reason i keep getting colourbanding. using papybmp or not. also i noticed that no matter what i enter for bpc say, 8,8,8,8 - i always end up with 5,6,5 (rgb). i might be a littler denser than the average crowd in this regard :D. that aside i spent some ridiculous amout of time on the windscreen :rolleyes: and am getting where i want to. planes and everything. jeez this planes concept is driving me up the wall. for some reason the entire way the cockpit is built is giving me moments where i want to slap someone senseless, but then i get back to it, fiddle some more only to see it doesn't yield the result i want, go drive some (end up driving some more..).
anyway.
the windscreen in the attach is what i want it to be. i just don't like the way it's done - there's some buggery involved that rather annoys me, looks ok sitting still though. now i need to finally get around to fixing the fire extinguisher handle and the inside cockpit walls.

btw aren't these mirrors the wrong ones on the car? i noticed in the file(s) that there is some with two actual supports - much like the real car - yet idk how to get them to show up.

anyway, finally a screenshot again, yay. (oh yea, the top half of the shifter, wtf? someone added lots of specularity there or highlights or something?

Attached Files



#36 MECH

MECH

    Double poly killer

  • Administrators
  • PipPipPipPipPipPipPipPipPipPip
  • 2,408 posts
  • Gender:Male
  • Location:Here ->
  • Interests:My Girlfriend
  • Sim interest:GPL

Posted Jul 05 2009 - 07:39 AM

The mirror construction in the ferrari resides in the cockpit node of the car.
You probably already noticed this since you are altering the windscreen.
If you go down the branches you eventually will find the mirror backside (in 3d, see red lined object)
Behind that structure the mirror.mip is called (this is just a flat polygon calling the mirror.mip, see yellow lines)
Next the mirror rim is called (yellow lines) and uses the mipname frim that is mentioned in the 1a8fc node.
By using transparency the backview (frim.mip) is overlayed on the mirror.mip

So basically you need to use a positioner to move the mirror 3d structure a bit outwards.
You can use the one at adress 1a910, it will move the entire structure. Just change the y value a bit and you'll have a sticking out mirror.

The only thing you need to do then is adding the 2 supports by either adding 2 mips or by replacing the entire mirror structure by using an external 3do which you create in 3dsmax  ;)
Personally i think adding 2 mips would be easier, the tricky part is getting them positioned before or after the mirror by putting them in the right draworder.

The shifter has probably specular lighting added. So if you would remove all shiny stuff from the mip it would still have glare. I think the specular lighting is based on the positioning of the normals within the polygons.
I just checked the shiftfe.3do and it has normals but they aren't being used by the 3do file  :confused:  
So it could be that it uses global lighting since it can't determine it by polygons with normals.

To remove or reduce the specular lighting you can use 3doconvert.
It expects a 3do to have a normals section. If it hasn't got a normals reference it won't work.

Attached Files



#37 Jumi2

Jumi2

    Erzkanzler

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 386 posts
  • Gender:Male
  • Location:Wooooohooo
  • Interests:Sports, Guitars.
  • Sim interest:GPL

Posted Jul 06 2009 - 06:30 AM

:o I think it looks amazing! Keep it up, its getting there!

#38 Jumi2

Jumi2

    Erzkanzler

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 386 posts
  • Gender:Male
  • Location:Wooooohooo
  • Interests:Sports, Guitars.
  • Sim interest:GPL

Posted Jul 17 2009 - 08:31 AM

I am currently doing a new bt24 dash, is 2048x1024 for the whole thing enough? I also plan on doing a set of smiths gauges we could use for other dashes, since they were widely used at that time. Anyone got a clue what font they used for lettering/numbers? cant be to fancy i guess. As always any pictures of cockpits for the brabham and/or gauges are welcome.

Edited by Jumi2, Jul 17 2009 - 08:34 AM.


#39 Akseli - guest

Akseli - guest
  • Guests

Posted Jul 17 2009 - 08:42 AM

View PostJumi2, on Jul 17 2009, 05:31 PM, said:

I am currently doing a new bt24 dash, is 2048x1024 for the whole thing enough? I also plan on doing a set of smiths gauges we could use for other dashes, since they were widely used at that time. Anyone got a clue what font they used for lettering/numbers? cant be to fancy i guess. As always any pictures of cockpits for the brabham and/or gauges are welcome.

The bigger the better. Resolution can be always reduced for those who wants lowresolution dashes ;)

#40 sky

sky

    ultra highres junkie & 917 addict

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,550 posts
  • Gender:Male
  • Location:the last haven for petrolheads
  • Interests:travel, music, racing, vintage cars, model cars
  • Sim interest:GPL

Posted Jul 17 2009 - 12:37 PM

View PostJumi2, on Jul 17 2009, 04:31 PM, said:

I am currently doing a new bt24 dash, is 2048x1024 for the whole thing enough? I also plan on doing a set of smiths gauges we could use for other dashes, since they were widely used at that time. Anyone got a clue what font they used for lettering/numbers? cant be to fancy i guess. As always any pictures of cockpits for the brabham and/or gauges are welcome.


awesome jumi!!! and yea, my dash is 2 bits of 1024x1024 so i think you're bang on there. going any higher would mean 4096x2048.. and that's pretty slick but way out. especially since you need to be running the game at resolutions of almost similar dimensions, preferrably twice the texture size (lol) - i don't think there's screens for that just yet.

regarding the smith gauges. i did some research a while ago - while hunting for the fezza gauges and things and i found a picture that was about the best quality i came across, which is still not that good. but anyway. also in that picture you will see the "made in england" at the bottom of those gauges that is always missing in any of the gpl cockpits i have found. sure for labels this small 4096 would be awesome, but then again, the dash is a bit away from the camera at 78° fov, so it will not be the full size, and hence it will be scaled, so it will always be somewhat blurry - an experience i had to make ;). mips=0 helps a bit though :D

fell free to post your progress in here. i'd love to see it!!
in case you have some "jaeger" dials as well.. here's a pic with labels. not as highres as i would wish for, but fair enough
attached are the best shots of the bt24 dash i have amassed since starting this thread, not much i have to admit, but maybe they'll help you out somewhat.


i'm about done with the red bits of my '69 fez, so on to the gearshift and the dreaded upholstery. colin really did a sterling job with his there. we'll see if i can match that. it will be a major effort, of that i'm sure.

/edit
jaeger logos:
http://styleandfashi...69A3FF07834.jpg
that pic is like 3500 x 2000 pix (jaeger lecoultre) tag. it needs slight tilting forward in photoshop and you could use it as a pretty solid basis for recreating the jaeger type.
or this one:
http://styleandfashi...A44584C399B.jpg
saved both of them as i might need to do jaeger dials myself at some point :D

Attached Files


Edited by sky, Jul 17 2009 - 12:43 PM.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

Sim Racing Links