A new height map mode - support for REALLY large worlds

uzik

03-03-2007 01:05:28

Good evening all,

I'm in the process of testing out a new height map mode that
eliminates the overhead for having really large worlds. Is there
any interest in this? If so, what's the procedure for submitting
patches to PLSM?

The code uses a single bitmap to store the height data for the
entire world. Because of the way the data is formatted there
is much less overhead loading parts of the bitmap from disk
than loading it from individual files. It eliminates the need
for a mapsplitter tool since the height data can be prepared
with any image editor.

Have a good weekend

bibiteinfo

03-03-2007 05:54:39

Wouldn't you need a HUGE bitmap to do so??

It could be interesting, but you still need to load the image in memory, so it could be a bottleneck at some point.

And a bitmap after all is just data giving heights.

uzik

03-03-2007 20:40:00

Yes, you do need a huge bitmap. With current machines and current off the shelf image editors I assume you could edit an image as large as free memory. If you have 512m free that gets you a bitmap about 13k on a side.
A high end machine with several gig of RAM could edit a larger image.
A special editor could be made that could edit any size image, but that
would require someone to write it. The smaller sizes can be done
with off the shelf photoshop.

The idea behind this code is NOT to load the entire bitmap in memory.
You can use some very simple math to calculate the position within the
file of any specific pixel. Loading a terrain page from the file just requires
loading that portion of the file. Since you never load the entire image
you can have a world as large as disk space or a 32 bit operating system
allows, with zero overhead.

I did some tests. Opening and reading 1000 files of 8k each is two
orders of magnitude slower than reading one file with 8000k on my
win2k box

kungfoomasta

03-03-2007 22:53:07

Is there
any interest in this?


Definately sounds like its worth looking into!

For submitting patches, I think you just email them to tuan.

KungFooMasta

Rowan

04-03-2007 02:15:17

Add me to the list, I'd be very interested in this.

PLSM2 is great, but with faster page loading and no map splitting, it would be close to perfect! :D

uzik

04-03-2007 02:27:39

I'm debugging it now. I'll try to get a binary demo put together
for download. Since I'm such a noob to ogre it's going much
more slowly than I'd like. I intended to do the same thing to
the terrain texturing as well, but I'm not sure if anyone would
be interested in that. I did find out I seem to have reinvented
the megatexture http://en.wikipedia.org/wiki/MegaTexture
except for heightmaps.

Rowan

04-03-2007 02:50:42

Great, regarding the texturing, I would be interested in that also.
It would be good to remove the map splitting step entirely if possible, but there a number of different types of maps PLSM2 uses so I can't say how difficult that would be ( I'm generally happy with whatever I can get..lol ).

At the moment, I'm actually only using 1 big color map, plus a single detail material pass, to texture my heightmap ( to save performance ).

As in that MegaTexture reference you linked, it seems the more detail you can pre-generate the better in terms of in game performance.

Alexander

04-03-2007 03:50:44

This sounds pretty interesting. :D

asmo

04-03-2007 11:04:45

Wouldn't it be better to add this to PLSM3?

uzik

04-03-2007 16:31:22

I'm developing this for my own use, and since I don't have plsm3... ;)

Is the timeline pretty long for plsm3? I thought plsm2 was just
released and plsm3 might be many months away yet.

It won't take much effort to add to a separate source tree in either
case. It involves adding a derived class and adding one line to the
existing code that registers the available modes.

uzik

04-03-2007 18:19:55

Does anyone have any ideas what causes it to not correctly
put the seam between pages? Do you just always load an extra
row and column to cover the overlap?

http://www.reddawn.net/~uzik/images/mws.screenshot_1.png

Grom

04-03-2007 20:09:20

yes I believe you do, that's why all the pages are like 513x513, and yet they all add up to 1025, or 2049

jacmoe

04-03-2007 21:20:06

I must be dense, but I don't really see the point of this ... :)

The mapsplitter takes huge images as input and splits them.

It's an off-line tool, which saves run-time CPU and memory.

You're saying you want to put real-time map splitting into PLSM?

Hmm .. Doesn't seem very efficient to me.. :?

jacmoe

04-03-2007 21:21:32

On the other hand..
What would be great is if PLSM could handle pre-split images, like the ones you get from L3DT, which handles really HUGE worlds through paging.

uzik

04-03-2007 22:02:02

I must be dense, but I don't really see the point of this ... :)

The mapsplitter takes huge images as input and splits them.

It's an off-line tool, which saves run-time CPU and memory.

You're saying you want to put real-time map splitting into PLSM?

Hmm .. Doesn't seem very efficient to me.. :?


It's two orders of magnitude faster to read all the data from
one file than it is to read the same exact data from a bunch of files.

If you do separate files what happens each time you load a page?
1. look up the material in the resource manager
2. resource manager searches all the file systems you put in via config files
3. it asks the OS to open the file
4. the OS searches the directory list (if there are a lot of files in that
directory this is very expensive)
5. the OS assembles the list of clusters on disk that makes up the file.
6. if it's a compressed file you decompress the data

If you do one file you only pay the price for steps 1-5 once, at startup, not every time you load a page. Each time you load a page from a large file:
1. calculate offset into file of page
2. seek to that position in the already opened file.
(both of those steps are very fast)

The CPU impact is much lower for large file. My test showed it was
more than 100 times faster to read the
same data from one file than to read from 1000 files.

The memory footprint is the same because you never load the
huge file into memory, only the portion you need for each page.

uzik

04-03-2007 22:14:55

Actually it looks like with a little rewriting RAW mode would be
a little better in terms of quality of terrain, but I don't think any
of the off the shelf image programs will display or edit a RAW
format image.

nindim

05-03-2007 00:09:50

Adobe photoshop cs2 can edit many types of raw files, you must know the correct format and size etc though to open correctly.

uzik

05-03-2007 01:06:56

Thanks! I'll probably make up a version that uses raw format too.
It could give you smoother terrain

nindim

05-03-2007 10:12:38

16-Bit raws would be a really good feature to have cause of the added detail in the height range. Sounds pretty interesting what you're doing, as long as your tests work out the same when used with the PLSM2 (which I'm sure they will) ;)

uzik

05-03-2007 13:40:07

I have the seam problem fixed.
I'll try and put together a timing test on it today.
As the medical researchers say "It works in the petri dish",
now to see if it really works.

I started with PLSM2 from CVS so it should be trivial to integrate with
the current code tree.

nindim

05-03-2007 13:48:39

sounds good, keep us posted!

uzik

06-03-2007 00:57:17

I'm going to package up a binary demo shortly.

I did the benchmarks today. Loading separate BMP files as
a heightmap turned in a best time (for loading 256 heightmaps)
of 578ms. The new paged mode loader turned in a best time
of 437ms. I chose the fastest of five runs in both cases.
This is only 25% faster, which surprises me. I would have
expected a lot better. I imagine compressed files like jpg's
would add a lot more time due to image decompression.

Rowan

06-03-2007 01:19:23

Would you be able to explain a little how this is working in comparison to an identical PLSM2 technique now?

Ie: are you are loading the entire heightmap into memory from Disk on startup, then when PLSM2 calls a new page, you load that page into the SceneManager from the memory?

And, would the same idea using current PLSM2 methods be to set the SceneManager to load all Pages on initialization, ie: set MaxAdjacentPages & MaxPreloadedPages to their maximums?

Aside from any speed improvement, removing the need for splitting can't be a bad thing IMO.

uzik

06-03-2007 03:56:26

are you are loading the entire heightmap into memory from Disk on startup, then when PLSM2 calls a new page, you load that page into the SceneManager from the memory?

No. It never loads the entire map. It only loads the portion of the map
needed for a terrain page.

Example: If the page manager requests the page
for x=5, z=4 it calculates the offset into the file for that page, seeks
to that position, then reads the pixels for the size of the page you
specified in the config files. In my case a page is 128 by 128 pixels.
It reads that much then stops.

It leaves the file open at all times and shares a single file handle
among all requests. That way you don't waste time opening
and closing the same file repeatedly. The overhead for an open
file is very small.

the same idea using current PLSM2 methods be to set the SceneManager to load all Pages on initialization, ie: set MaxAdjacentPages & MaxPreloadedPages to their maximums?

I don't know the details of those settings you mention, I'm new
to PLSM2 too and still trying to learn how it all works. I will answer
the question I think you asked:

You might get a better speed benefit by loading every page you'll
ever need at startup. If you're doing that then I assume your
world is small enough to fit in memory. If that's true you probably
want to look at the TSM terrain manager instead. It doesn't do paging
and that scenario doesn't need it. The advantage of the paged
algorithm is that you can have an almost infinitely large world with
smaller memory overhead (you don't have to load it all).
The page manager in PLSM manages loading and unloading the pages
of the world you need.


Rowan

06-03-2007 05:48:44

Ok, thanks for the clarification. So the overhead of multiple file opening & closing is reduced to a once-off event only.

This might help reduce the page-loading pauses when the camera is moving quickly ( useful for flight sims among others ).

I'm looking forward to seeing how it goes when you're done.

Anonymous

06-03-2007 14:05:45

This might be a nice optimization - an improved page loader for plsm2. You'll have to benchmark it in a real-world situation to see whether the effect is noticeable...

Two things:
Firstm the mapsplitter tool actually does more things than just to split the terrain - so to maintain the same functionality of plsm2 you would still need it even with a new loader.
Second, the name of this topic is confusing. Your technique would have absolutely no effect on the size of world that can be represented - that is dictated by the number of tiles you can keep in memory. In order to represent (on screen) truly huge worlds we will have to wait for geomipmapping approaches (like plsm3).

<edit>
hm... reading back this post I notice it reads like I am putting you down. In fact I think this is a great idea: get rid of all the little page files and possibly speed up loading in the process! Great!
</edit>

uzik

07-03-2007 01:44:48

Your technique would have absolutely no effect on the size of world that can be represented - that is dictated by the number of tiles you can keep in memory

I don't believe that's true, but maybe I missed something. Since I never load the entire heightmap for the world into memory at any time you could have easily a heightmap file as large as your operating system or disk space will permit. There's no extra memory overhead. The settings for the page manager will determine how many pages it caches. The same applies to the textures. Was there a limiting factor I missed?

It did occur to me that photoshop (and all other image editors) will probably only let you open a file that can fit into memory so you can't edit the terrain file if it gets too large. I think I might be able to hack Gimp to fix that problem though.


The mapsplitter tool actually does more things than just to split the terrain - so to maintain the same functionality of plsm2 you would still need it even with a new loader.


I'm still not up to speed on that tool. I know it does a lot of things for texturing but I don't believe you need it any longer for heightmaps.

reading back this post I notice it reads like I am putting you down

No worries. Thanks for the consideration. :)

nindim

07-03-2007 02:27:32

Off the top of my head as well as splitting heightmaps the mapsplitter generates lightmaps use with texturing mode. It also has tuan's horizon lighting system built into it (i think) As well as that I believe it generates coverage maps based on height for use with splatting.

uzik

07-03-2007 02:45:37

Thanks :)
Is there a good discussion of how the lightmaps work anywhere?

Anonymous

07-03-2007 11:17:37

I don't believe that's true, but maybe I missed something.
Well, maybe I missed something.
The whole point of a paging scene manager is that you don't have to load the whole map into memory at once, and this is what plsm2 does. My point is that you still have to load the visible tiles into memory, so the landscape area that can be visible at any one time is still limited (this is where geomipmapping comes in - farther away areas take less memory). Other than that, the size of the landscape is bounded only by floating point precision.

In fact, there might be a problem with the mapsplitter tool and really large images... haven't tried. In any case, mapsplitting is an offline process so it won't affect system specs for running the app.

uzik

07-03-2007 13:51:42

In any case, mapsplitting is an offline process so it won't affect system specs for running the app.

Write yourself a test application, or if you like I'll send you the code,
open and read the contents of 1000 files and time it. Then create a
file that is the same size cumulatively as the 1000 files. Open and
read it. As far as you're concerned you've performed the exact
same amount of total work. You got the computer to read X bytes of
data. You'll find the single file read is much faster. The overhead of
asking the OS to open and close files 1000 times is reduced to
opening it one time.

the size of the landscape is bounded only by floating point precision
That might be the real limiting factor. Good catch!

Anonymous

08-03-2007 13:39:40

Write yourself a test application, or if...

I am fully aware of that... still loading times in no way limits the amount of terrain that can be loaded into memory, right? My point is that you might get a faster page loading using another loader, but it won't affect the max size of terrain... either on disk or in memory.

About testing in general: always test optimizations in the context they will actually be used. You might find that the overhead from opening files is unnoticeable in the context of a real application. Even at pageLoad there is a lot more going on than just reading the file, and considering you might load a page every... say 10 seconds max (there might be exceptions, of course), the total fraction of time your application spends opening files might be unnoticable.

uzik

08-03-2007 13:51:10

About testing in general: always test optimizations in the context they will actually be used.

I did. It's 25% faster.

uzik

08-03-2007 13:51:37

I will post source code on my web site if anyone is interested in
trying it out.

Does anyone have experience using
the "tracker" system? In another forum post the moderator
said just "post your patch to the tracker". I've never used
patches or cvs I have a number of questions. Seems like I've used
every other source code control system on earth, but
that one, of course!

kungfoomasta

08-03-2007 19:22:32

I'm pretty noob with creating patches, but with TortoiseCVS I think you can just right click on the folder or files, and under TortoiseCVS click the Patch menu item. This will generate a .patch file, email that to Tuan, or PM him with a link to the patch file.

KungFooMasta

Anonymous

08-03-2007 22:18:25

I did. It's 25% faster.

I think you do not understand me completely. You say loading 256 bitmaps (128 * 128 pixels, right?) takes 578ms, whereas loading one big bitmap takes 437ms. This means each bitmap takes around 2ms to load. From those 2ms, around 0.5ms is spent opening a file. When running at 60fps, this represents the 1/32 of a frame. Now... in a real world application a page is not loaded every frame, but far, far, more seldom. In an application that load a lot of pages - say one every 20s, this means saving 0.5ms every 20s - or 0.0025% (if I got the math right...). This, of course, comes at the expense of only using uncompressed images for terrain.

kungfoomasta

09-03-2007 00:19:16

I'm curious.. what image formats would be considered uncompressed?

KungFooMasta

uzik

09-03-2007 01:02:34

I'm curious.. what image formats would be considered uncompressed?
KungFooMasta


Right now it only works for type 2 or 3 uncompressed Targa images. Targa also supports RLE compression but that makes it much slower to calculate where a pixel will be located within the image file. The image also cannot be stored in a ZIP file, for the same reasons. This algorithm trades disk space for execution time. If you want a large detailed world it will eat up a lot of disk space. This seemed a worthwhile tradeoff for my application, particularly with the cost of hard disk space these days.

asmo

09-03-2007 08:46:31

I have to agree with martin.enge, I highly doubt you gain 25% performence boost in a real world use of it and you will not be able to use bigger landscapes than if you were using splitted files.

Anonymous

09-03-2007 09:34:14

Also (sorry, now I can't stop) using 128*128 (shouldn't it be 129*129, by the way) size pages is very uneconomical - use 513*513 and let plsm2 split it into tiles for you. If you extrapolate from you timings (might be not very accurate, but anyhow) this would mean that reading 256 513*513 pages would take around 16*472ms ~ 7.5s. Opening a file still takes 0.5ms, so now you saved around 1.5% in your "pure loading" example. In the case of loading a page every 20s, performance gain is the same, of course - 0.0025%.

Again... not a bad idea as an option... just want to keep peoples expectations realistic :roll:

uzik

09-03-2007 14:28:35

The total time performance of the application is a worthless measure.

How long do you run a game for? You run it until you're done playing.
You can see this in every screen shot posted here. What measure do
the put into the debug overlays? FPS. Frames Per Second. Nowhere
do you see total time measured. The important measure is how much
can the code be tweaked to maximize responsiveness. I presented code
that helps boost responsiveness.

I compared apples to apples and presented the results, both in
a test rig and as a part of the library.

My measurements show it's faster, it requires less up front
work to use, and is simpler to configure. The down side is that it
requires the file not be inside a zip archive.

Even if this code was enthusiastically embraced by the PLSM
developers it's written as a plugin so it's use is completely optional.
If you don't want to use it please feel free not to.

Thanks for your input, but I really have more positive things to do
with my time than to argue about minutiae.

Anonymous

09-03-2007 16:06:37

Well I think it is a good contribution - said so twice already! My posts were meant as food for thought, not to shoot you down. Sorry if I misjudged the thickness of you skin... I am sure your efforts will be appreciated by plsm2 users.

kungfoomasta

09-03-2007 19:08:05

Isn't that like a compliment sandwich, or something? When you embed a negative comment in between 2 positive comments? martin.enge, even if you pretend to throw out nice comments, I still sense an insult in your response.

That and your arguements seem very theoretical and speculative. Most people find it easier to believe somebody when they toss out numbers and percentages. Its funny that you are shooting down the concept without having tested it yourself.

I for one would like the idea of not using the mapsplitter at all. One map is simple and easy to organize. That, and not all of us have 1 scene. I could have dozens of really large terrain in my game, and I don't want to keep track of thousands of heightmap and colormaps.

KungFooMasta

Anonymous

09-03-2007 21:48:48

Well sense what you want, I do think this is a viable idea. Do I have to spend as many words repeating this as discussing problems with the approach or be considered an enemy of the idea? And I am certainly not trying to insult anyone.

We all know emotions are not well transmitted through these kind of forums. So I'll just have to hope for you to believe my words as written...

Grom

09-03-2007 23:14:40

kungfoo as far as I understand it, you will still need to run mapsplitter to split up your color maps, uzik's improvements apply only to the heightmap.

unless you're using splatting.

kungfoomasta

10-03-2007 00:34:23

doh! Well thanks for the clarification. Me personally, I wish there was a PLSM2/TSM hybrid, as I use smaller size scenes, but I'd like to use deformation and splatting.

KungFooMasta

uzik

10-03-2007 01:00:44

kungfoo as far as I understand it, you will still need to run mapsplitter to split up your color maps, uzik's improvements apply only to the heightmap. unless you're using splatting.

That's true, but

It did occur to me that this would work for textures too.
So for those of you that don't use dynamic texture generation I have
a texture mode that loads from an unsplit image almost ready too.
I have to check it over a little more before I want to post it (unless
someone wants to volunteer to help test it... ;)

I'll post the code for the heightmap this weekend.

Game_Ender

10-03-2007 03:58:02

kungfoomasta its called damning with faint praise.

Anonymous

10-03-2007 09:47:35

Me personally, I wish there was a PLSM2/TSM hybrid, as I use smaller size scenes, but I'd like to use deformation and splatting.

Tuan talked about turning the mapsplitter into a library, which can be used either offline or by your app has been discussed. Don't know what came of that.

Anyhow, the mapsplitter could probably easily be modified to output non-compressed non-split height-, coverage-, etc maps for use with the new loader.

uzik

10-03-2007 15:06:10

Thanks Martin, that's a good idea to pursue. If Tuan includes my code in his release it'll be worth a look.

The source code can be found here:
http://www.reddawn.net/~jsprenkl/ogre/

If anyone needs it I can provide a Microsoft VC8 version of the
DLL but I don't have facilities for anything else right now.

I have a demo program running but something about it bothers
me. It does the same thing the PLSM2 demo does. It doesn't load
pages at any distance from the camera. I'm not sure if it's supposed
to do that but it sure seems wrong to me. Does anyone else get
that behaviour?

Anonymous

10-03-2007 21:24:04

It doesn't load pages at any distance from the camera.
I do not understand what you mean exactly. Please be more specific.

asmo

10-03-2007 22:08:02

@uzik
I understand that you want to hold your idea high, which is fine, but to advertise 25% boost is just not true. martin.enge has a point, and a good one at that. I really think that what you are doing is greate, but the mass usage of plsm is by people who just use it and who lack real experience. They are the same people who will sit for hours trying to get that 25% boost. They will fail, of course. Other critical things to fix are reseting scenes, which is not working well (dead nodes) and good splatting shaders (built in support for four textures / tile).

This is good, but '.. REALLY ..', capital, no.

kungfoomasta

10-03-2007 22:19:50

@asmo

I expect you have already taken his code and used it then? If you have, why not state that. If not...

KungFooMasta

asmo

10-03-2007 23:48:08

@asmo

I expect you have already taken his code and used it then? If you have, why not state that. If not...

KungFooMasta


I have gone through the code quite fast, so no, I can not state that. The code is not the point, however, so how can that matter?

The thing here is that speed is not relevante for this kind of things. Ease of use matters, and that is where I think this may come to use, but speed, no. Do you even think twice to put your GUI code in LUA or python becouse it is slower? Hell no. It's the same thing here. If it makes life easier to produce maps, sure, but I will care less about loading times of pages.

uzik

11-03-2007 00:31:20

@uzik
I understand that you want to hold your idea high, which is fine, but to advertise 25% boost is just not true. martin.enge has a point, and a good one at that. I really think that what you are doing is greate, but the mass usage of plsm is by people who just use it and who lack real experience. They are the same people who will sit for hours trying to get that 25% boost.


I'm at a loss to see what your aim is here.

If you want to take the code and do your own tests please feel free.
I will be happy to place your results on my page with my own.
I compared the existing image paging load code against my code to
get that figure. If you're trying to state my figures or methodology
are wrong please back it up with your own test results so I can see
what's wrong and learn from it.

If you're trying to state that other people will misunderstand
the claim I don't see how other people's inability to understand
how things work is my fault or my problem.

I try to contribute and I feel I'm being attacked for it.
I have the impression you and Martin have an emotional
need for this to be wrong and you're searching for any
way you can find to make it wrong. If it will make you happy
I will remove all my claims that the code is faster.
Will that satisfy you?

kungfoomasta

11-03-2007 00:32:25

So there is a design phase, and an implementation phase. During Design, you can speculate, theorize, study things and come up with ideas, etc. The problem is that Uzik is in the implementation phase. It is already written out in code, and does not need to have arguements that are merely from looking and thinking about it. He provides the code, and has run it himself. If you wish to dispute his claims, the best way to do so is to run his code and measure performance on your own machine. This shouldn't be a problem, as a link is posted to his code. This is absolutely ridiculous.. it's pretty much your word vs the author's, with the exception that the author has run this and measured performance.

If you don't support his idea, then don't post. If you don't want to contribute, then don't post. If you want to sit back and analyze, which in no way actually helps his current implementation, please do so without posting, and do not share your negative opinions and unbacked information. What is the purpose of your posts? To discourage him?

KungFooMasta

[edit] I see you posted at the same time Uzik. I too get the idea that you are being attacked for this. It honestly makes no sense.. [/edit]

tetsu

11-03-2007 02:50:55

I can't see any attack. I think both kungfoomasta and uzik misunderstand the point of the others posts. The point isn't that they think uzik's contribution is unnecessary, they don't. They have clarfied that several times. What they are saying is that the figures he come up with isn't representative with how it would be in a more general game-like environment.

So why are the other posters "worried", is it a problem to proclaim those numbers? That depends...if there are people that don't know or understand uzik's test then they might think they will get 25% more fps or something, with uzik's implementation.

uzik

16-03-2007 12:03:06

I've finished the RAW format loader and corrected a mistake in the documentation on the web page. The raw format version
allows up to 65536 distinct heights instead of 768 and the
heightmap file is 33% smaller. I've found that Photoshop will
happily edit/create this type of file and even edit one larger than
memory (my art friends say "It will take all day though")

Enjoy

http://www.reddawn.net/~jsprenkl/ogre/

Rowan

16-03-2007 12:15:36

Nice work, I will definitely be trying this out, RAW support is good too.

One question, do you know if this will work alongside the other image-map types PLSM2 uses which are generated ( as split pages ) by mapsplitter, ie: normal maps, lightmaps?

uzik

16-03-2007 22:49:38

Nice work, I will definitely be trying this out, RAW support is good too.

One question, do you know if this will work alongside the other image-map types PLSM2 uses which are generated ( as split pages ) by mapsplitter, ie: normal maps, lightmaps?


Yes, it will. The heightmap data produced is the same from all the different modes.

I do have an on demand paging texture mode working but I haven't
tested it with shadows,etc. yet. I'm not sure if it has any value.
The option of making a photorealistic landscape might be nice but
if it renders too slow it might be worthless.

Rowan

16-03-2007 23:05:52

Ok.

Re the paging texture mode, I would guess the 'singular-file-open' overhead saving concept would work there too, & for any of the image file types that are paged by PLSM2.
So the loading speed benefit might add up if you are loading a few different types, ie: HeightMap + TextureMap + LightMap, etc..

Not that I am trying to create more work for you.. :D

EDIT:: I just realised that the lightmaps are generated by mapsplitter in pieces so I guess that wouldn't be applicable currently (without modification to mapsplitter ).

uzik

17-03-2007 03:19:10

Re the paging texture mode, I would guess the 'singular-file-open' overhead saving concept would work there too, & for any of the image file types that are paged by PLSM2.
So the loading speed benefit might add up if you are loading a few different types, ie: HeightMap + TextureMap + LightMap, etc..

Not that I am trying to create more work for you.. :D


Yeah, I thought the same thing too. I did create a working
texture mode that does the same thing as the image per page
mode. I still have a bug to work out with it. I've got a small
math error so it's showing seams where the pages meet.


EDIT:: I just realised that the lightmaps are generated by mapsplitter in pieces so I guess that wouldn't be applicable currently (without modification to mapsplitter ).


As I learn more about how the internals of ogre and plsm
work I may be able to do these others. It might be possible
to completely eliminate the splitting function and just have it
generate a single lightmap.

nindim

17-03-2007 19:36:51

In relation to lightmap creation through the use of the mapslitter, it appears to be broken just now (at least in cvs) ALso the sdk version on Tuans site produces strange effects, for a simple flat plane it adds noise everywhere. As far as I know Tuan has moved on to his dynamic lightmap mode using sun on z-axis I believe so i dont think that he's mantaining it just now...