Re: How does texture loading work?

New Message Reply Date view Thread view Subject view Author view

From: Angus Dorbie (dorbie++at++sgi.com)
Date: 03/21/2000 10:45:47


This is very strange.

A texture will either be all loaded or it won't be initially. Just load
the image and it works. One call to setImage should be all you need.

You MIGHT be seeing previous contents of TRAM, but that wouldn't be very
consistent. It seems likely that you are confusing x & y in some
function call somewhere.

CHeers,ANgus.

christopher.g.dorosky++at++lmco.com wrote:
>
> I am seeing some strange things with texture memory downloads and want to
> clarify something.
>
> I have a very large building, which has a 1K*1K texture associated with it,
> with one quarter of the texture covering each wall.
>
> If I never explicitly do a texture->load(), and the texture is not in
> texture memory, but the associated image is in regular memory, and I fly
> around to see only one wall, what happens?
>
> Does the pipe
> A) Download the entire texture to texmem and render the 1/4 it needs
> B) Figure out the 1/4 it needs and download that portion.
>
> I am in the middle of a disastrous attempt to preload textures before I need
> them. Cliptexturing already handles the terrain, I just have problem with
> buildings. If I try to preload the whole texture at once, it takes an
> excessive amount of time. If I try to break it up, it is much worse.
> Incredibly, the best results come from not preloading anything, and letting
> the pipe handle everything automagically. Unfortunately, this results in
> occasional frame hiccups, which I am trying to eliminate.
>
> I have tried the pfutexturemanager, but it doesn't seem to understand the
> cliptexture, and the automatic load function with the maxtime on it simply
> takes a list of textures, and loads an entire texture, and checks to see if
> it overran the max time before continuing. Does anybody have an example of
> preloading a large texture in a real-time friendly manner?
>
> I have a feeling I am making this much harder than it has to be. Any
> suggestions would be appreciated.
>
> Christopher Dorosky
> Senior Electronic Systems Engineer - Real Time Simulation
> Lockheed Martin Missiles and Fire Control - Dallas
> christopher.g.dorosky++at++lmco.com
> 972-603-2349
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com

-- 
For Performer+OpenGL tutorials http://www.dorbie.com/

"In the middle of difficulty lies opportunity." --Albert Einstein


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Tue Mar 21 2000 - 10:45:58 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.