mohij
-
Posts
244 -
Joined
-
Last visited
Posts posted by mohij
-
-
Shall I beautify the other functions the way you did? I guess that makes sense.
-
greebo, you simply rock. Wow.
-
New version with all expressions completed and smooth normals refactored to use Vector3
The SmoothNormals doesn't work correct and I'm quite stuck, because I really can't explain the faulty result...
Should look like this:
-
-
Ok, now I understand, thanks for those explanations. I'll try to change this to a singleton.
-
For a game manager that makes sense (since there can only be one), but with a texture manipulator that is a class of which logically any number could exist (with threads even at the same time), that seems strange. To me it sounds quite strange to make classes singletons which logically aren't, just as a speed hack. Or did I misunderstand that?
Following that thought it means that there is no actual data saved in this class (since the same class can be used in different cases), so the class actually just wraps up functions.
Wouldn't it then be better to just provide the functions directly? (this doesn't sound object oriented, but why make a class out of something which is really just functions?)
Please don't feel offended, it just doesn't seem right to me.
-
Now that it's obvious that we'll need this scale function/class, could you (greebo) please explain what exactly you meant by turning the TextureManipulator into a singleton? I don't really understand how that makes sense (singleton = only one object of that type, right?).
-
But it would be good to know anyways.
What I know for sure now is that in map expressions the second image is scaled to the size of the first.
That different dimensions are possible is obvious too, but what I'd find interesting to know is what sets the final size of the texture in game. (whether a texture is "two feet" or "20 feet" high.)
It seems the resolution has no influence on that. Could it be that by default all textures are the same size?
-
I did a small test, and it seems to scale the second parameter to the resolution of the first one.
I also noticed that the resolutions of the images are not responsible for the size of the final result. I guess the diffuse map resolution does set the size finaly. I will test and report results. (so in the end all images in a material file will have the same resolution, I'll just have to find out which one sets this final resolution).
-
The scale problem could be solved in two ways. Either scale one image to the size of the other (probably the higher resolution image to the lower) or don't scale the images and use the getPixel function, that won't scale the images, but repeat the small image. Both seem logical, so no idea which one is correct.
Scaling the image would require a scale function (perhaps there already is one in there I don't know of?), writing my own would be quite some work, an alternative would be a hack to divide the different widths and heights and step through the bigger image with a different offset, but that's no nice solution.
-
Well then, latest progress:
implemented are: heightmap, addnormals, smoothnormals, add and scale.
The rest should be relatively easy.
Since there are no material files I can try the add and scale on, I can't say if they work.
-
Do you have any material files using those MapExpressions, or at least some information what the values exactly do?
-
-
I just finished the smoothnormals Expression. But it seems there is no way I can test it, since no material in doom3 seems to use it 8-|. Could someone help me out with a material file?
-
-
I completed the AddNormals, but the results don't look the way they should.
Any ideas what could cause that?
Solved it.
-
My first try would have been to write a normalize function, as I will probably need that one more often. And then simply iterate through the image (I wouldn't even need to differentiate between RGB) add the values together and divide by 2. After that a call to the normalize function would do the trick.
That is much simpler and the result would be the same, right?
I'm not 100% sure, normalize means trimming a vertor to a length of 1, right?
Edit: Wikipedia helped.
-
I noticed a bug: in GLTextureManager.h line 85
virtual TexturePtr GLTextureManager::getBinding(const std::string& fullPath, const std::string& moduleNames) = 0;
the GLTextureManager:: shouldn't be there.
Small question, is it intended, that you use two different descriptors for the second argument? In ishaders.h and GLTextureManager.h you use "moduleNames" and in GLTextureManager.cpp "fileExt".
What are you working on next?I will continue with the AddNormalsExpression. Some information on what this function (and later on the others too) should actually do would be helpful. The alternative would be trying some implementations and see which one mimics Doom3s implementation best, but that doesn't sound fun...
Edit: and about the critics, I am very grateful for them, since they really help learning, and that's what I want to do ;-)
-
Ok, fixed this.
Link: MapExpression.zip
-
The problem is that I changed getBinding to take MapExpressions, so I'm forced to use MapExpressions all the time, even if I just need to realize a path which has nothing to do with a MapExpression.
I think even better would be to change the GLTextureManager to take such a "bool useFileLoader" instead of a MapExpression. Logicaly that makes more sense too.
Edit: or even better change the
GLTextureManager::getBinding(const std::string& filename
to default to using the FileLoader and just let the caller create the MapExpression.
-
Yeah, this is the second time MapExpressions fail because they use the DefaultConstructor and not the FileLoader.
First thing that comes to my mind is overloading the createForToken/createForString functions to take a pseudo argument: "bool useFileLoader=0", but it could be that there is a more elegant way of solving this. But on the other side the question arises if it makes sense to interpret paths as MapExpressions, because in the end a MapExpression was not meant to be a path (that's just a hack to make life easier).
-
I'm not sure how that could happen. Since we fixed the bug with returning white images instead of ShaderNotFound, it is more logical that a ShaderNotFound is returned, when a call is faulty.
The relevant line:
mapExp = IMapExpression::createForString(GlobalRegistry().get("user/paths/bitmapsPath") + IMAGE_BLACK); -
I think I found a bug. The "shaderNotFound" texture shows inverted colors on negative normal angles. This has nothing to do with the NormalMap thing, as it already happens before those changes.
-
I forgot to upload the .h file, sorry for that. But you found the correct values, so I guess it wasn't a problem ;-)
MapExpressions
in DarkRadiant Feedback and Development
Posted
I cleaned the MapExpression.cpp up, always have y first in for clauses, removing a lot of whitespaces and bring the scaleexpression to a usable state by inserting some error checking.
MapExpression.cpp