There is a famous function from WebGL API (and from OpenGL too) getAttribLocation http://msdn.microsoft.com/en-us/library/ie/dn302408(v=vs.85).aspx
In my project I'm trying to get the needed attribute by using this function, but getting the -1 value.
It's ok, when there isn't such attribute in shader, but in my program there is:
See it? I've dump in console the existed members of shaders, and vertexColor exists.
I don't know how can I get -1, when the dump of shader from which I'm fetching attributes shows that such an attribute exists in memory.
If to fetch other attributes, all is normal, except this one (but it was declared in same way as others and I didn't delete something in memory):
As you can see for vertexPosition and textureCoordinatesAttribute it returns their location number of the attribute.
So what's wrong and why does it occur I can't explain. Please help with a piece of advice.
Can't provide a source code, because I'm developing large library, which is right now 3k+ lines of codes. I can only tell you that you may see how shaders are creating by the screenshots and the function, which is getting attributes is just iterating a collection of the input objects with attribute list, and for each attribute is calling getAttribLocation function from WebGL. Despite on this, the screenshots show the real dump, and you can see, that I'm telling the truth about existed attributes in shader. Also, you can see that fetching two of them gives a correct result and one fails. What's wrong I don't know. As for me and if to use logic it must not return the -1 value. The attributes exists in memory and the calling syntax is correct, so this issue is rather mysterious for me right now.
If the attribute is not used the GLSL compiler is allowed to optimize it out. The WebGL API is designed so you can ignore that. Passing -1 to any of the functions that take an attribute location basically become a no-op.
Similarly the GLSL compiler can optimize away unused uniforms. gl.getUniformLocation will return null for unknown uniforms and passing null to any of the functions that take uniform location are a no-op
It's a good thing it works this way because when debugging it's common to comment out parts of a shader. Because unknown attribute and uniform locations just become a no-op everything just keeps working, no errors.
Related
Assume I have a Manipulate with two dynamic variables and I want to put the corresponding controls in a Row for aesthetics reason. I can think of two ways to do it as follows:
Row[Control/#{{{a,a_in},a_min,a_max},{{b,b_in},b_min,b_bmax}}]
or
Row[{Control[{{a,a_in},a_min,a_max}],Control[{{b,b_in},b_min,b_bmax}]}]
The issue is that in the first case after the 1st run of the cell containing Manipulate with that line the variables a, b become having defined value (a_in and b_in) respectively and for further evaluation are not recognized as variables of Manipulate, while in the other case a and b remain undefined and serve correctly as dynamic variables.
I expect that the Map (/#) somehow changes the order of evaluation in the expression and that the variable "leaks" outside the Row, gets told by Manipulate to have a value and takes it on. While on the other hand the simple Control[] correctly encloses a control option and nothing "leaks". Yet I find this claim possibly false and unsatisfyingly vague (thus hard to generalize and understand Mathematica better, which I would like to).
Can someone explain why that happens or point me to some other insightful answer (I guess this is not the first time this issue came up, but I can't form a proper query to google for it.)?
I need to replace old version of boost (1.58) with a new one (1.66). But there is an issue with a breaking change that happened since then in boost::geometry library. I have little knowledge in this library. In the code that I depend on (not written by me) function self_turns() is used. As far as I understand it calculates self intersections. In previous version it required 4 parameters, but in the new one it requires 5 (plus 2 optional). New parameter is IntersectionStrategy. I searched a lot but failed to find any documentation or examples of how this can be defined/used. Does anyone know how it should be used now?
You can try to pass a variable declared like this:
typename bg::strategy::intersection::services::default_strategy
<typename bg::cs_tag<Geometry>::type>::type strategy;
(where Geometry is your geometry type, and bg an alias for boost::geometry) as the missing Intersection Strategy
No, there are no samples yet, it is meant to be a public function in the future but currently it is not (and therefore the interface can change indeed).
I was asked the question below and I am stuck. I understand the difference between value & reference, but do not know when I would use each in a method.
If you were writing a method, which parameter passing method would you choose, if any? Why?
I found this below to help me get a grasp of the differences.
"If I tell you the URL, I'm passing by reference. You can use that URL to see the same web page I can see. If that page is changed, we both see the changes. If you delete the URL, all you're doing is destroying your reference to that page - you're not deleting the actual page itself.
If I print out the page and give you the printout, I'm passing by value. Your page is a disconnected copy of the original. You won't see any subsequent changes, and any changes that you make (e.g. scribbling on your printout) will not show up on the original page. If you destroy the printout, you have actually destroyed your copy of the object - but the original web page remains intact."
Keep in mind, passing by value makes a copy. There might be two reasons not to do this. First, if the value you are passing is some large data structure (or anything else that uses a lot of memory), it is probably inefficient and unnecessary to copy the entire thing. Second, if you want any changes to the parameter to be mirrored in the calling function, you must pass by reference. That way, the original value gets modified, not a copy.
When neither of those cases apply, passing by value is usually simpler and a better option.
There's one other thing to consider. Passing by value, since it creates a copy, protects the value in the original function from accidental modification. However, you may want the performance benefits from passing by reference. In this case, it is good practice to pass by reference, but mark the parameter as const (or whatever is appropriate in your language).
I am a fresher of OpenGL ES2.0 and GLSL, and I want to use shaders to process Images. When I coded in Xcode, I used built-in variables such as gl_Normal, gl_Vertex directly and did not declared them at the beginning of shaders. At last, I got a error message:
Use of undeclared identifier gl_Normal. why?
Use of undeclared identifier gl_Normal. why?
In OpenGL-ES 2, and following in its footsteps OpenGL-3 core, there are no longer predefined shader input variables. OpenGL-4 did even away with predefined shader outputs.
Instead you're expected to define your own inputs and outputs. Each input or output variable as assigned a so called location. Either implicitly by OpenGL, and retrieveable by glGetAttribLocation, or explicitly by the programmer using the location storage qualifier attribute or glBindAttribLocation function. Outputs are similarily assigned by fragment data locations.
I'm looking at a piece of very old VB6, and have come across usages such as
Form5!ProgressBar.Max = time_max
and
Form5!ProgressBar.Value = current_time
Perusing the answer to this question here and reading this page here, I deduce that these things mean the same as
Form5.ProgressBar.Max = time_max
Form5.ProgressBar.Value = current_time
but it isn't at all clear that this is the case. Can anyone confirm or deny this, and/or point me at an explanation in words of one syllable?
Yes, Form5!ProgressBar is almost exactly equivalent to Form5.ProgressBar
As far as I can remember there is one difference: the behaviour if the Form5 object does not have a ProgressBar member (i.e. the form does not have a control called ProgressBar). The dot-notation is checked at compile time but the exclamation-mark notation is checked at run time.
Form5.ProgressBar will not compile.
Form5!ProgressBar will compile but will give an error at runtime.
IMHO the dot notation is preferred in VB6, especially when accessing controls. The exclamation mark is only supported for backward-compatibility with very old versions of VB.
The default member of a Form is (indirectly) the Controls collection.
The bang (!) syntax is used for collection access in VB, and in many cases the compiler makes use of it to early bind things that otherwise would be accessed more slowly through late binding.
Far from deprecated, it is often preferable.
However in this case since the default member of Form objects is [_Default] As Object containing a reference to a Controls As Object instance, there is no particular advantage or disadvantage to this syntax over:
Form5("ProgressBar").Value
I agree that in this case however it is better to more directly access the control as a member of the Form as in:
Form5.ProgressBar.Value
Knowing the difference between these is a matter of actually knowing VB. It isn't simply syntactic though, the two "paths" do different things that get to the same result.
Hopefully this answer offers an explanation rather merely invoking voodoo.