mohij
-
Posts
244 -
Joined
-
Last visited
Posts posted by mohij
-
-
I copied the HeightMap thingy over. I put some materials that use the heightmap expression on a brush, but I'm not sure how the result should look like. It is colored and bumped, is that correct?
Edit: compared to current head, and that seems to be correct (since current head does not bump)
Edit2: am I meant to upload this now? I have no information whatsoever on how to do this.
-
Well I do roughtly understand what it does (those comment lines, though rare give some hint to what actually happens), but understanding how Edge Detection and in this case the Prewitt filter works is a different thing (my brother said this is stuff for fourth term in university ;-).
Hey, I just saw that you already created a new branch, cool, thanks.
-
Where is that piece of code from? I think it will take some time until I fully understand edge detection, as this is the first time I deal with stuff like that.
-
A HightMap is defined by the greyscale image and a scale value. Does someone know how this parameter is defined? Ideal case would be a relation to the pixel distance (like 1=from white to black is one pixel distance, 0=means no distance (the image is ignored), 2=two pixeldistances, and so on).
-
OK, here the link (just the shaders folder and ishader.h, as before):
I guess it will work with newest head.
-
Ok, new version is on ftp, same link as before. I didn't change anything except fixing this bug and removing my bug-hunting code. No idea if a seperate svn branch is worth it, but it would be surely helpful, because I wouldn't have to upload those MapExpression.zip files ;-)
-
Would it be a good idea to commit the changes, so the interface is set? That would also make it easier for me, since I could finally update my checkout again.
-
Well then, let's proceed to actually implementing the MapExpressions :-)
-
Found the mistake. In loadStandardTexture I produced the image via a MapExpression, which uses the DefaultConstructor. The old version uses the FileLoader. It seems the DefaultConstructor can't handle .bmp images.
-
Just started again, and I am completely puzzled now. I made getBinding only return getShaderNotFound, so my changes are completely out of the job, and still the blocks are white.
edit: Thinking about it a bit more, that obviously means the error must be in loadStandardTexture, and I even found some changed stuff, I think I'll have solved it soon.
-
Works with the newest changes
-
Well, I didn't change anything (except code to find the error). What I found out: getShaderNotFound() is called. I can't check if it is called as often as with old code, since current svn is broken, in case you don't know:
radiant/csg.cpp: In function 'Face* Brush_findIf(const Brush&, const Predicate&)': radiant/csg.cpp:214: error: operands to ?: have different types
Also strange is where such a white texture could come from, as it is a valid image something must have produced it, no idea where it should come from.
I'm still looking into it.
-
You understood correct, but anyways, I'll just leave it the way it is. I think this stupid white texture bug is more important atm.
-
I meant removing the class entirely, as the only place it is used is the ImageExpression::getImage().
But it's also no problem to keep it, I just thought that it might be nicer to remove it.
I'm not sure what you mean with turning it into a helper class, it already is a nice small class, isn't it? And how could it even work as singleton, there could very well be more than one of it, or am I mistaken?
-
I tested bumpmaps and dynamic lightning and it works.
I will try to find the shadernotfound error. And after that I can finally actually start to implement the MapExpressions :-)
Completely off topic: should I copy the texture constructor over to ImageExpression::getImage() and remove it?
-
Hm, after seeing the correct way it should be done, it looks quite simple... yeah, next time...
Strange, with those exact changes my radiant still shows white textures instead of Shader not found... could a full recompile solve this?
-
About the NULL pointer and the "control reaches end of non-void function", I had those fixed already, even though I did it with references. I changed it to pointers now.
About shared pointers and .get()-> ... changed that, very good to know, thanks. If I had known that before... ;-)
Sorry about the formating, I use (vim)
set softtabstop=4 set noexpandtab set shiftwidth=4
Which means an indenting of 4, but with the standard tab width of 8 (rest is filled up with spaces).
Logical mistake in CShader: yeah, right, got those, thanks.
Will upload the new version. The code looks definitely nicer, but the default texture is still white and not "shader not found".
-
Added another check for empty textures into getBinding, and now radiant works (with adding a brush, haven't tested anything else for now). But the brush is plain white (with standard texture).
Texture browser shows a lot of white textures, but some also show correctly. It seems that just the "shader not found" texture does not work.
Edit: In dynamic light mode the textures show no change to no dynamic light mode.
I will probably not be able to continue on this until tomorrow evening :-(
-
-
Crashes on creation of brush, so no idea if MapExpressions work ;-)
The first (old) crash/assertion happend in getBinding where the GLTextureManager got an empty MapExpression and asserted. If I understand it right it shouldn't assert on empty MapExpressions, but produce the getShaderNotFound(). (if I interpreted it right the old getBinding did exactly that).
The current crash happens in GLTextureManager::load, because the getBinding parsed it an empty image. But since it checks for empty MapExpressions I wonder how it is possible that such a MapExpression returns an empty Image.
Well I guess it's quite hard to understand what I talk about when you didn't read the code... If you are interested I could send you my plugins/shaders folder.
-
Ok, I'm freaking out right now!!! I implemented it with the second approach (and there is some obvious flaw in there, but I don't entirely understand the problem yet) and radiant STARTS!!!!
Edit: but segfaults on creation of a brush :-(
-
Atm my Radiant aborts, because
GLTextureManager::getBinding(MapExpressionPtr mapExp)
gets an empty MapExpressionPtr.
The old version of the MapExpressions had a function which, according to comment, evaluates to an empty texture, so getBinding worked.
If I understood the problem right, I have two possibilities, either introduce empty MapExpressions also and roll it up the way it was in the old code, or modify getBinding to check for empty MapExpressions and then return the empty texture. The second way has the disadvantage that any error checking is bypassed. So what'd you say?
-
YEEEEEEEEEHAAAAAAAAAW!! First successful compile!!
It segfaults, but anyways. *happy*
-
Completely offtopic question. While compiling I get these warnings (after every file). Once I tried to fix them, but I didn't understand much. Is that important enought for a bug?
radiant/winding.h: In function 'void Winding_testSelect(Winding&, SelectionTest&, SelectionIntersection&)': radiant/winding.h:373: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/math/Vector4.h: In member function 'const BasicVector3<T>& BasicVector4<Element>::getVector3() const [with Element = double]': libs/math/matrix.h:439: instantiated from here libs/math/Vector4.h:291: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/math/Vector4.h: In member function 'BasicVector3<T>& BasicVector4<Element>::getVector3() [with Element = double]': libs/transformlib.h:71: instantiated from here libs/math/Vector4.h:287: warning: dereferencing type-punned pointer will break strict-aliasing rules
MapExpressions
in DarkRadiant Feedback and Development
Posted
OK, file is online on:
MapExpression.cpp