rec.autos.simulators

> >Hi Guys....

> >Well, unfortunately we have a problem with all four track re-texture jobs
> >I've done in the last two months.

> >The good news is....its not a problem for those of you running GF4 cards
> >with high-end CPU's.  If you run your video card settings as per my
"tweaks"
> >log
> >(www.pabst-racing.com/websreens/tweaks.xls)  then the problem is not
> >apparent in N2K2.  If you have any other video card....or a slow CPU,
> >there's no current "fix" for this problem at this time.

> >What's The Problem?
> >There's a purple haze coloring to distant objects.....trees, towers,
> >grandstands....are the most likely to show it.

> >Why?
> >Because the mip mapping compression routine used by WinMip2 (created by
> >Klaus Horbrand) has a bug that doesn't adhere to the command indicating
the
> >graphic file's "transparent" color.

> Well, I'd say with those purple pixels in there, any card that does
> h/w generated mipmaps would have the same problem. I think. ;-)
> What the LOADER should do is kill of all purple pixels, replace them
> with say black+alpha=0, and THEN generate mipmaps.
> Ofcourse, use .tga's with alpha and you're all set. :)

> If WinMip2 creates the mipmaps itself then that's possible, but odd. I
> create mipmaps only during loading time. Saves some disk space, and
> CPU time wasted is so low these days so it doesn't make a difference.
> And it should be done by the gfxcards anyway in the end.

> So do the WinMip generated files actually include all the mipmap
> levels already? (ofcourse that means you are able to give those
> mipmaps a nicer filter but still)

> Ruud van Gaal
> Free car sim: http://www.racesimcentral.net/
> Pencil art  : http://www.racesimcentral.net/

"Biz" <biznos...@worldnet.att.net> wrote in message

> What is your problem?  If you don't want to use his stuff, don't.

> could work as flawlessly as the original textures, he does them for

> his system, so he owes you no explanantion.  Why don't you grow a pair and

> is NOT WELCOME here.
> --
> Biz

> "Don't touch that please, your primitive intellect wouldn't understand
> alloys and compositions and,......things with molecular structures,....and
> the....." - Ash

> Schooner <schoo...@accesswave.ca> wrote in message

> > Whatever Tom.  I know how to tweak my settings thanks. If you don't want
to
> > reply then don't feel a need to.
> > Perhaps learn to take a bit of criticism from time to time, like myself
you
> > are not correct 100% of the time either.
> > And please don't assume if I have a good enough system or not or that it
is
> > optimized, not sure how you assumed it's not but I guess that's your way
of
> > feeling big is to run others down without information.
> > What you assume are "correct" settings are based on your opinion, not
fact
> > or industry known proofs.
> > I'd appreciate you not spouting off as the expert in all areas when
clearly
> > you are not.

> > What you said was "Well, unfortunately we have a problem with all four
track
> > re-texture jobs I've done in the last two months.
> > The good news is....its not a problem for those of you running GF4 cards
> > with high-end CPU's."
> > From that I got the impression that the textures only worked properly
with a
> > GF4 card which you state.  You seem to believe that all people with a
high
> > end system would be running a GF4 but many of us use ATI in our high end
> > systems.

> > "Tom Pabst" <tmpa...@attbi.com> wrote in message
> > news:ic5d9.345749$UU1.59502@sccrnsc03...
> > > Schooner...

> > > I'd prefer not to even answer your reply......because apparently
making
> > sure
> > > your system settings and video card settings are correct and optimized
for
> > > FPS and max quality graphics levels "is a chore" for you.  That's
fine,
> > and
> > > I don't care one way or the other if you run these track re-textures
or
> > not.
> > > Its your loss, not mine (assuming you have a system strong enough to
do
> > so).
> > > But, you keep making misleading statements, which could deter someone
else
> > > from running them who would like to have better, more realistic track
> > > graphics.  Therefore, I must reply.

> > > I did not say the "re-textured" tracks work only on Nv cards.  I said,
> > "they
> > > are optimized" for Nvidia cards.....as are just about every graphic
> > upgrade
> > > created today in the sim world.  So, are the original track textures
in
> > most
> > > sims as well.  "Optimized" does not mean "works only on" - now does
it?

> > > The "settings" discussed as necessary to avoid seeing the "purple
haze"
> > > around some objects on the track are the settings one should be using
in
> > the
> > > first place.  Those reporting the "purple haze" clearly don't have
their
> > > video card "properties settings" correct (as was recently discovered).
> > > Correcting that issue is "not jumping through hoops."  Its correcting
a
> > > mistake the user has made.  Making those corrections will not only
prevent
> > > the "purple haze" on my re-textured tracks....but it will also
> > substantially
> > > improve the graphics on all tracks...in ALL sims!

> > > I'd appreciate you stop trying to "knock something around"....just
because
> > > you are not familiar with it.  Okay?

> > > Regards,

> > > Tom

> > > "Schooner" <schoo...@accesswave.ca> wrote in message
> > > news:Ej0d9.55068$C8.146381@nnrp1.uunet.ca...
> > > > You also said it only worked on nVidia cards not just an issue on
low
> > end
> > > > systems.  I appreciate the work but seems like a lot of hoops to
jump
> > > > through to get them to work is all.

> > > > "Tom Pabst" <tmpa...@attbi.com> wrote in message
> > > > news:39Uc9.338029$UU1.57962@sccrnsc03...
> > > > > Schooner...

> > > > > This didn't cause any "corruptions" of any existing
> > files...........its
> > > > > nothing but a "visual anomalies" on lower end systems....which you
are
> > > > > advised in the readme.txt file not to use these track textures
with
> > > > anyway.
> > > > > If your system is up to snuff.....try them, you are missing some
nice
> > > > > realistic looking track graphics.

> > > > > TP

> > > > > "Schooner" <schoo...@accesswave.ca> wrote in message
> > > > > news:xRRc9.54908$C8.143712@nnrp1.uunet.ca...
> > > > > > Thus the reason I avoid most add-ons and tweaks, they can cause
more
> > > > > > problems than good.

> > > > > > "Tom Pabst" <tmpa...@attbi.com> wrote in message
> > > > > > news:NERc9.95008$kp.741548@rwcrnsc52.ops.asp.att.net...
> > > > > > > Hi Guys....

> > > > > > > Well, unfortunately we have a problem with all four track
> > re-texture
> > > > > jobs
> > > > > > > I've done in the last two months.

> > > > > > > The good news is....its not a problem for those of you running
GF4
> > > > cards
> > > > > > > with high-end CPU's.  If you run your video card settings as
per
> > my
> > > > > > "tweaks"
> > > > > > > log
> > > > > > > (www.pabst-racing.com/websreens/tweaks.xls)  then the problem
is
> > not
> > > > > > > apparent in N2K2.  If you have any other video card....or a
slow
> > > CPU,
> > > > > > > there's no current "fix" for this problem at this time.

> > > > > > > What's The Problem?
> > > > > > > There's a purple haze coloring to distant objects.....trees,
> > towers,
> > > > > > > grandstands....are the most likely to show it.

> > > > > > > Why?
> > > > > > > Because the mip mapping compression routine used by WinMip2
> > (created
> > > > by
> > > > > > > Klaus Horbrand) has a bug that doesn't adhere to the command
> > > > indicating
> > > > > > the
> > > > > > > graphic file's "transparent" color.  Instead, it includes the
> > > > > transparent
> > > > > > > color in the compression averaging.  This means, the mip
> > sub-images
> > > at
> > > > > the
> > > > > > > low end.....get this purpose haze around the objects in the
file
> > > > (trees,
> > > > > > > grandstands, light poles, etc.).

> > > > > > > What's the Fix?
> > > > > > > There isn't one until Klaus finds the bug and fixes WinMip2.
Even
> > > > then,
> > > > > > I'm
> > > > > > > not inclined to go back and re-do all these files....unless he
> > also
> > > > > fixes
> > > > > > > the "batch conversion" routine in WinMip2 at the same time.
If I
> > > have
> > > > > to
> > > > > > go
> > > > > > > back through all these files one by one....and re-convert them
by
> > > > > > > hand.......that will take about 15 minutes per file....and
there
> > are
> > > > > over
> > > > > > > 1200 of them.  Ain't no way I'm going to spend 300 hours doing
> > this
> > > so
> > > > > > those
> > > > > > > of you with low-end systems don't have this problem.
> > Sorry...that's
> > > > > just
> > > > > > a
> > > > > > > fact of life.

> > > > > > > I will keep you posted through this string only.......until I
hear
> > > > back
> > > > > > from
> > > > > > > Klaus as to his "prognosis."

> > > > > > > Please do not email me about this....I already have plenty of
> > > > > screenshots
> > > > > > to
> > > > > > > show this problem, I don't need any more.

> > > > > > > Thanks,

> > > > > > > Tom

> >Ruud...

> >First of all, the use of the "purple color" for a transparency color is
> >something not unique to Papyrus.

> Right, I have purple keying in Racer as well. But it's still a bit
> ancient by now. Just use alpha channels and you're set (it's cleaner I
> think, although it takes a bit more memory yes).

> >Back in the old N3 days and initial GPL graphics upgrades days.......Papy
> >didn't use this bright pink very often.  Why?  Because the mip
compression
> >routine used by DirectX (I assume DX dictates this...but not totally sure
of
> >it....perhaps there's a "game industry" graphic artists who visit r.a.s.
who
> >can clarify this)....didn't allow for the "compression" to actually
ignore a
> >designated "transparent" color.

> Probably because there is no transparent color. It doesn't exist on
> graphics cards. You create it by treating pink as transparent, but on
> CPU only; you then should create an alpha=0 black pixel or something
> and not leave the pink*** around.
> Compression, like JPEG, kills exact color info so there goes your
> transparent color that must be exactly 255,0,255.

> ...
> >Papy's mip files.....for as long as I've been doing graphics on their
> >tracks, do contain the "sub-images" within the mip.  This is unlike EA
> >sports track graphics (for example), which are bitmaps and the "hardware"
> >compresses them and mipmapps (to subimages) them as well.

> Which is more future-oriented. Doing your own mips enables you to use
> a better filter, but then things get small and with anisotropic
> filtering, well, why bother anymore.

> >  I don't know why
> >papy does it this way, I'm sure they have a very good reason and perhaps
> >someone can tell us.

> Probably legacy stuff; GPL's rendering system is truly ancient and
> targeted at Voodoo-type cards; 'if you can miss pushing a triangle to
> the card then it's worth it'. Not true anymore these days.

> >What I can tell you is that the
> >low-level subimages are somehow not adhering to his programming command
to
> >"ignore the field transparent color" in the compression averaging routine

> He's most probably simply using a box filter:
> Take 4x4 pixels:
> abcd   => (a+b+e+f)/4  (c+d+g+h)/4
> efgh      (i+j+m+n)/4  (k+l+o+p)/4
> ijkl
> mnop

> Very non-proprietary. :) But it filters in the pink with other colors,
> obviously. As I said, there is no transparent color unless you make
> all your functions listen to such a thing. With alpha channels, you
> don't have this problem, you just boxfilter away.

> >As you can see....."the use of .tga's" or any other graphic file format
is
> >not an option....when re-texturing papyrus tracks for N2K2.

> Right; it was just a comment in general. BMPs are old & crappy (no
> support for 32-bit), just like GIF which didn't support 24-bit; what
> WERE they thinking?
> But BMPs are supported natively on Windows, which is why it's used
> much. But the format is not really the format of choice for racing sim
> textures, I'd say. Because of that very 'can't use purple'
> restriction. Entirely unnecessary and problematic with mip-generation
> (unless ofcourse you translate the BMP 24-bit into 32-bit where purple
> gets converted, which is what I do).

> > I think David
> >Noonan uses some of the same conversion "techniques" that Klaus
does....but
> >I don't think they use the same programming/converter.  I could be wrong
> >about that.  As far as I'm concerned, my "hobby" of doing these track
> >graphics is only possible because of Klaus...and in the past, because of
> >David.  I thank them a million times, every time I can.

> I'm not saying that Klaus did a bad job; I was just trying to clarify
> how things work behind it all, so it's easy to see why you get
> filtered pink into the mip images.
> And easy enough to fix to.

> >Sorry for the length of this response....but its somewhat of a
complicated
> >topic....and I'm a "wordy SOB" anyway! ....lol...

> Hehe, true. :)

> >PS:  Some day, I plan to try to do some graphic work on your "Racer"
> >tracks......if I can find the time.

> Try .tga files! ;-)
> Or Photoshop .psd's, for all I care, works too. :) (but it's slower)

> Ruud van Gaal
> Free car sim: http://www.racesimcentral.net/
> Pencil art  : http://www.racesimcentral.net/

> ...
> >It looks like the DirectX includes under certain circumstances the
invisible
> >color(s) into the calculation for the resulting color in the lower mip
levels.
> >I was told, this would be a desired effect. The artist has the
possibility to
> >decide by choosing the invisible color how the texture blends into the
> >background when seen from far away.

> Hm, ofcourse blended filtering can be good or bad, whichever the
> artist wants, but blending in pink into mipmapped levels will result
> in halfly-pink colors, which I don't think are ever ok.

> ...
> >For I have no influence on the conversion process - the DX Texture tool
is kind
> >of a black box - all I can do with WinMip is to change the texture before
it is
> >handed over to the compression tool.

> Which is I think the best thing to do. I convert purple pixels
> (admittedly hardcoded at 255,0,255) to black & transparent (0,0,0,0).
> That makes filtering with whatever algorithm (meaning: taking into
> account transparent colors or not) quite acceptable.
> For objects like trees I think blending the (0,0,0,0) color would be
> ok, as it makes the leaf edges smoothish. For fences, a harder
> approach might look better.
> But to avoid transparent colors bleeding into actual pixels I just
> modify them upfront before handing them over to OpenGL (or in your
> case, DX's DXT1 compressor).

> > Will mean I built in an algorithm which
> >optimizes the colors of the invisible pixels so there are most likely no
color
> >changes at the lower mip levels, no matter which invisible color has been
> >chosen by the texture creator.

> Right.

> >I have not heard of Tom yet, but the results of my test look very
promising. He
> >will not have to redo his textures. Theres only a WinMip batch
conversion
> >mip->bmp and then back bmp->mip necessary and the "purplization" is gone.

> Sounds promising. :)

> Cheers,

> Ruud van Gaal
> Free car sim: http://www.racer.nl/
> Pencil art  : http://www.marketgraph.nl/gallery/