PaintPoint Error

ochensati2

27-12-2006 00:36:06

Hello,
I saw that this has come up before, but I couldn't find the post again. I am working with GOOF and trying to paint a texture on the landscape. This causes a the program to completely crash, so I tracked the error down and found that in the sub Paintpoint, in OgrePagingLandScapeTexture.cpp, the var currChannel is iterated larger than the vector (*channelModifList), crashing the system.

I tried to intialize currChannel to zero, but then mImages(k).getdata(); returns a bad pointer on when k=1.


Have you seen this error? You replied last time that currChannel should iterate larger than the array, but this seems like an error. but I am pretty rusty with C and trying to remember all the issues.


for (unsigned int k = 0; k < mNumTexture; k++)
{
uchar * const BaseData = mImages[k].getData();
assert (BaseData && "PagingLandScapeTexture::paint()");
const unsigned int currImagePos = imagePos * mNumChannelperTexture[k];
assert (currImagePos < mImages[k].getSize ());
assert (mNumChannelperTexture[k]*8 == mImages[k].getBPP ());
currChannel=0;
for (unsigned int j = 0; j < mNumChannelperTexture[k]; j++)
{
BaseData[ currImagePos + j ] =
static_cast <uchar> (
((*channelModifList)[currChannel]) * paintForce * bScale
+ BaseData[ currImagePos + j ] * invPaintForce
);
currChannel++;
}
doTextureNeedUpdate[k] = true;
}

ochensati2

27-12-2006 17:38:24

Ok, this works. I am sure that I am missing the intension of this code, but everything looks really nice with the painting


void PagingLandScapeTexture::paintPoint (const unsigned int imagePos,
const Real paintForce)
{
assert (mNumTexture > 0);
assert(mParent->channelModifList);
const std::vector<Real> *channelModifList = mParent->channelModifList;
const uchar bScale = 255;
const Real invPaintForce = 1.0f - paintForce;
unsigned int currChannel = 0;
for (unsigned int k = 0; k < mNumTexture; k++)
{
uchar * const BaseData = mImages[k].getData();
if (BaseData){
assert (BaseData && "PagingLandScapeTexture::paint()");
const unsigned int currImagePos = imagePos * mNumChannelperTexture[k];
assert (currImagePos < mImages[k].getSize ());
assert (mNumChannelperTexture[k]*8 == mImages[k].getBPP ());
currChannel=0;
for (unsigned int j = 0; j < mNumChannelperTexture[k]; j++)
{
BaseData[ currImagePos + j ] =
static_cast <uchar> (
((*channelModifList)[currChannel]) * paintForce * bScale
+ BaseData[ currImagePos + j ] * invPaintForce
);
currChannel++;
}
doTextureNeedUpdate[k] = true;
}
}
}
} //namespace

Falagard

28-12-2006 04:15:31

Great! Thanks for the fix, it'll help later when I'm working with the PLM2 again.

ochensati2

28-12-2006 19:17:02

I dont think it is the correct solution, but it does seem to work. I have been playing with the editor and it looks cool




I noticed that the editor inserts objects at the position of the cursor on the screen. Seems like it would be easier to insert them at the ground and then move them up if needed. What is your opinion on this?
The other bug is that the compound objects do not seem to load. I will get to that one next.

Falagard

28-12-2006 22:17:16

The editor in CVS is very out of date. Feel free to work on the version you have, but the newest version has many new features and bug fixes (such as casting a ray and inserting the object where the ray intersects either the terrain or another object, and compound objects load and save properly).

The newer version of the editor is still a ways off. I've added a lot of stuff in the last 9 months, but need to add more before I'm ready to release. I want the next release to go something like this: "Hey, this GOOF editor and engine looks neat, let me download it. Wow, now I will no longer even think about anything else ever again."

At the moment I'm working on adding lightmapping directly into the editor. This means you insert meshes into the scene, click "generate lightmap" and presto. What this involves is a ton of crazy stuff - integration with an external renderer, in this case Gelato. Grouping meshes together based on size, merging them, generating unique UVs, and then splitting them up into their original meshes but with an additional set of UVs which are used for the lightmap texture. Then partitioning the scene into logical pieces and sending to the lightmapper into mutiple phases to not overwhelm it with a 10km x 10km outdoor scene. As you can imagine, this is a lot of work - I expect it to take me another couple months :-(

Teaser:



That image is rendered in Gelato - a scene was set up in GOOF with appropriate lighting, and then I simply click a button which converts all meshes to Gelato geometry, sets up scene lighting, and renders it. Now I have to work on finishing the merging/uv generation/splitting code and bake out the lightmaps, then work on the material manager / mesh object code in GOOF which will load the new meshes with the lightmapped materials.

Kentamanos

28-12-2006 22:56:04

Not that I mind, but I assume you realize Gelato only works on NVidia cards.

I also noticed that they have a beta of 2.1 which makes "baking" easier. Are you using that version?

ochensati2

28-12-2006 23:28:34

ahh, it is not fair to keep all of the code fixing to yourself. :P

This was a lot more fun than relearning c++ with hello world tutorials

ochensati2

28-12-2006 23:30:03

The castle looks really cool by the way.

Falagard

29-12-2006 00:02:04


Not that I mind, but I assume you realize Gelato only works on NVidia cards.


Of course. I've devoted a considerable amount of time to investigating Gelato, 3delight, and SunFlow, and many weeks with Gelato itself. You don't think I'd notice that Gelato only works with NVidia cards? Lol - just teasing btw. It's my opinion that it's not out of the question to say "in order to develop a game using this toolset (the lightmap baker for example) you must use this particular hardware setup. On the other hand, the architecture for this library (OgreBaker - it'll probably end up in ogreaddons) is designed to support various renderers. The reason that 3delight and SunFlow weren't chosen was because I was further along with Gelato than the other two. 3delight can do baking, but it isn't supported directly by the renderer and requires a trick. I'd prefer using something that directly supports baking, and so if I have problems I can ask the developers of the software for support. SunFlow is interesting, but early in development - lacks documentation and seems to be slower. It is pretty fast though considering it is Java. It does support baking but I'm not sure if it supports what I need to be able to cast shadows through transparent textures.


I also noticed that they have a beta of 2.1 which makes "baking" easier. Are you using that version?


Same answer as above, but replace "notice that Gelato only works with Nvidia cards" with "notice there is a beta 2.1". I've worked with 2.0 and then beta 2.1B5 and B6 was just released last week. There's a plugin for 3ds max that only seems to work on 2.0 (for me anyhow) and so I've had to switch back and forth.

Vectrex

29-12-2006 01:26:34

hopefully things like LiPSPM shadows (see sinbads blog) will replace alot of the need for lightmaps. But it'll be quite a while before they look as good, especially with transparent objects etc

Falagard

29-12-2006 01:57:56

LiSPSM is great for outdoor shadows (directional) but indoor scenes and complex lighting such as say... night time city (lots of lights... lights far into the distance)... are going to need lightmaps for a long time.

I've considered using a combination of both, since outdoor scenes in some types of games need day/night cycle and that's tedious with lightmaps. Also, ambient occlusion is still a decent idea even if you're using dynamic lighting and shadows because it adds extra depth to the scene, and the baking solution I'm using can output just ambient occlusion textures.

Kentamanos

29-12-2006 04:06:42

Of course. I've devoted a considerable amount of time to investigating Gelato, 3delight, and SunFlow, and many weeks with Gelato itself. You don't think I'd notice that Gelato only works with NVidia cards? Lol - just teasing btw. It's my opinion that it's not out of the question to say "in order to develop a game using this toolset (the lightmap baker for example) you must use this particular hardware setup. On the other hand, the architecture for this library (OgreBaker - it'll probably end up in ogreaddons) is designed to support various renderers. The reason that 3delight and SunFlow weren't chosen was because I was further along with Gelato than the other two. 3delight can do baking, but it isn't supported directly by the renderer and requires a trick. I'd prefer using something that directly supports baking, and so if I have problems I can ask the developers of the software for support. SunFlow is interesting, but early in development - lacks documentation and seems to be slower. It is pretty fast though considering it is Java. It does support baking but I'm not sure if it supports what I need to be able to cast shadows through transparent textures.


Reading other posts you've made, I'm sure you're keeping the design fairly modular so that another solution could possibly be put in later :). I should check out Gelato some more. Have you found the API to be pretty well designed and easy to use?

There's a plugin for 3ds max that only seems to work on 2.0 (for me anyhow) and so I've had to switch back and forth.

I wish they supported XSI (in addition to the existing Maya and 3DS Max), but from what I understand, most 3rd party developers complain about the difficulty of creating new renderers for it. Of course, market share might have a bit more to do with it.

Falagard

29-12-2006 04:25:31


Have you found the API to be pretty well designed and easy to use?


Yeah, Gelato is fine. It has a C++ API and a Python API, and also separately to these, the shaders files which do a lot of the work as well. They provide a lot of sample shaders, but to be honest they should have provided some more real simple examples on how to apply a texture to some geometry and also include transparency. That took me a few hours to figure out even though it was simple - mostly because of the lack of an example and no clear documentation on how it works.

The shaders themselves are pretty cool because you can easily chain them together - the outputs of one shader to the inputs of another.

Kentamanos

29-12-2006 07:32:49

Been playing around with it. The "pyg" files are pretty easy to mess around with, and seem they'll be pretty easy to port to C++ once you get it working like you want.

Did you use the "gelobj" input plugin to do your initial testing?

OvermindDL1

29-12-2006 13:48:11

Hmm... so no baking for me then...

Falagard

29-12-2006 14:52:44


Did you use the "gelobj" input plugin to do your initial testing?


No, I used the 3ds plugin because it has an option to export to a standalone scene instead of rendering directly from 3ds max. When you export, it generates pyg files for the meshes, a pyg file for the scene, and copies all textures and shaders into a single location. You can then close 3ds max and just edit and/or run the pyg file directly, which is nice.

Falagard

29-12-2006 18:37:13


Hmm... so no baking for me then...


Like I said, it all comes down to what baker (offline renderer) plugins are implemented for the OgreBaker library. A large part of the work is done before the baker gets the scene, such as merging the meshes, generating unique UVs, and splitting the meshes back apart. The baker plugin is actually just the interface to the external tool - it takes the meshes and converts them to whatever format the external tool needs, and calls whatever api functions are required to take the scene passed to it and render out the maps. I may work on either the 3delight or SunFlow version after Gelato, but even if I don't, someone could take a look at what was done for Gelato and do it themselves.

I'm guessing market share for Nvidia versus ATI is still close to 50/50, so it might affect half the developers out there. It's definitely an issue. I'd do some speed comparisons of Gelato versus 3delight before even attempting a port. I know Gelato is faster when doing some rough comparisons, but I need to try to reproduce exactly the same scene between the two of them and see how they perform. If Gelato is 10x faster than 3delight, I won't even bother (there's a big difference between waiting for 2 hours and waiting for 20 hours). If they're comparable, I'll be tempted.

tuan kuranes

12-01-2007 12:31:34

var currChannel is iterated larger than the vector (*channelModifList), crashing the system.

There is a known bug in material having multiple technique, like PLshadeLit.
in known bugs:
Reusing multiple times same exact texture with same keyword in a technique (pass1{Coverage} pass2{Coverage}) isn't treated as technique (pass1{Coverage.0} pass2{Coverage.0}) but as (pass1{Coverage.0} pass2{Coverage.1})

can you explain the fix you made or at least list difference with actual code ?
Did you try it with PLSM2 demo and map, and all demoed texture mode ?

ochensati2

12-01-2007 17:06:02

hmm, it has been a while, but Looking at the code I made two changes

First I set,

uchar * const BaseData = mImages[k].getData();
if (BaseData){



The pointer was returning as a null pointer

second, currChannel=0; before the for loop each time.

currChannel kept wandering where it wasnt supposed to be. I assume the error must be somewhere else in the code as the getdata call was returning a null pointer.

I only tried this with the GOOF editor.