mohij

OK, you are right, after a bit more inspection it seems it is in fact only called with the same key. I will drop that way of calling getBinding.

Not all the time, since the key is different sometimes (I think). Different problem: it is not allowed to include from the plugins dir, right? But when modifying getBinding to accept MapExpressions I need to modify the base class IGLTextureManager too. But to do that I would need to include the .h file from the plugins dir. Edit: btw. getBinding has 3 different ways to be called on my local copy: TexturePtr getBinding(MapExpressionPtr mapExp, const std::string& textureKey = NULL); TexturePtr getBinding(const std::string& filename);

Small question: Is this possible? TexturePtr GLTextureManager::getBinding(IMapExpressionPtr mapExpr, const std::string& textureKey = mapExpr.getIdentifier()) { Edit: No, doesn't work, solved it with an ugly if construct.

Small status report. Yesterday evening and this evening I spent on fixing compiler errors... atm I'm stuck on GLTexturemanager.cpp. I changed getBinding() to accept an Image& instead of a TextureConstructor. Problem is that empty Images need to be possible. And I didn't consider that non existant MapExpressions can't produce Images (not even empty ones ;-). So I guess I will have to rewrite the getBinding() to accept a MapExpression instead of an Image. Hopefully it will work afterwards.

Yeah, that's exactly what I wanted to do, that's why I asked about human readable

Does this identifier need to be human readable in any way?

The problem is, that the MapExpression can't know what material it is. The only thing it has is the Tokeniser (the Expression that produces them). So would it be fine to identify them by this expression?

If I understand right, the textures need to be identified with a definite string. I have no idea what string should be used to identify a MapExpression, since a MapExpression can be build up of more than one token. Any ideas? Edit: an idea I had is that every map expression also has a function std::string getName(); which constructs it's name from the previous ones and adds it's own part to it. No idea if that would be ok.

@greebo (second post): Ah, I know what you mean, you talk about the return optimization, right?

That's not possible, since there is no MapExpression class, only IMapExpression, which is virtual. So that's not possible. Edit: refering to your first post

greebo: I didn't try to compile it when I posted the links, but since then I'm on fixing compile errors, got quite a lot. Now it compiles. And I also changed some typedefs. About the p in return shared_ptr<IMapExpression> p(new MakeAlphaExpression (token)); the boost documentation says it's saver. OrbWeaver: so I'll try to change The ShaderTemplate. edit: I uploaded the new versions MapExpression.cpp MapExpression.h

In ShaderTemplate.cpp the constructNull function is used twice, should I implement that one too or change ShaderTemplate?

I finished the minimal MapExpressions. MapExpressionnew.cpp MapExpressionnew.h You can take a look if you want.

So best is not to have any data in there at all, ok.

class IMapExpression { Image result; /* will hold the image on first call of getImage(), further calls to getImage will simply return result */ public: static boost::shared_ptr<IMapExpression> createForToken(parser::DefTokeniser& token); virtual Image& getImage() = 0; }; Last question: Is this interface fine now (before I start to change everything to work with this one)?

Hehe, same-time post, the reply was meant for OrbWeaver. Your reply wasn't there when I started the reply. Sorry for the confusion.

That's not exactly what I meant, but I will just continue with the MapExpressions themselves.

Yes, understood. What do you think is better, first changing the surrounding files to work with the new MapExpressions and then implementing them (makes testing easy) or other way round?

Shouldn't that be: TextureConstructorPtr cons = IMapExpression->createForToken(tok)->getImage(); and now that we discussed it, with an Image instead of Textureconstructor.

Bypassing the TextureConstructor class would mean returning directly an image object? Just out of curiosity, would I have had to implement my own version of the textureConstructor class? I only found two implementations that both load from filename. Is the TextureConstructor class still needed when MapExpressions directly produce image classes? When the TextureConstructor is only needed for the MapExpressions (that's what it looks like atm), then I would probably remove it.

So here is my current progress: MapExpressionnew.cpp MapExpressionnew.h I just looked at the surrounding files and I think I will have to change some other files too to make them work with the new interface, right? Then this should be done first, so I can test the code I write. Should the processed images be saved at all (or just created every time the Shadersystem requests one) and if yes, where? In the Constructor: all MapExpressions would be evaluated, independent of their usage getImage could also be defined in the base class in getImage: either the MapExpression is recreated everytime it is asked for, or saved (either in the class or pushed to the texture manager) I think in getImage would be better. Different from the files above, I think it would be better to save the results instead of the arguments. Edit: I changed MapExpressionnew.h to reflect this.

What directory would be appropriate? There is a temp and a DarkRadiant dir. I just have the standard doom3 files, no idea if they suffice.

Forgot, there is also an "ImageExpression" which just returns an image. Edit: is there a way to upload files (.h and .cpp)? That would make things easier, as I could just paste the files I've written so far.

Well, what I have since now is: Base class: class IMapExpression { public: static boost::shared_ptr<IMapExpression> createForToken(parser::DefTokeniser& tok); virtual TextureConstructor& getImage() = 0; }; specific Map Expressions then look this way: class HeightMapExpression : IMapExpression { shared_ptr<IMapExpression> argOne; float argTwo; public: HeightMapExpression (parser::DefTokeniser& tok); TextureConstructor& getImage(); }; implementation for createForToken: boost::shared_ptr<IMapExpression> IMapExpression::createForToken(parser::DefTokeniser& tok) { // Switch on the first keyword, to determine what kind of expression this // is. std::string token = boost::algorithm::to_lower_copy(token.nextToken()); if (token == "heightmap") { return shared_ptr<IMapExpression> p(new HeightMapExpression (tok)); } else if (token == "addnormals") { return shared_ptr<IMapExpression> p(new AddNormalsExpression (tok)); } ... I'm not entirely sure where the images should be saved, inside the structures? Also not sure when they should be processed. Either when creating the class or when getImage is called. So, comments please

I'm back.