I'm just learning three.js and so far everything has been going good except for when it comes to textures. Whenever I try to apply a texture it doesn't work. And that's when I'm basically copying and pasting tutorial codes to tweak and all I'm doing is changing the image to one I have. The weirdest part is when the pathname is incorrect, it displays the object (in this case, the floor plane) all black as expected but when it is correct, nothing is displayed except the axes for direction. The tutorial is here. It's lesson 1 (though I've gotten to lesson 6 using plain colors as substitutes for textures), and the source code isn't on the page; you need to right click and view the page source. The part where the code applies the checkerboard texture is near the end in the section called 'floor'. Also, I even tried seeing if it was because it didn't load before it rendered but that's not the case.
Thanks
Related
I have an animation loop running in which I'm getting an error that reads...
GL ERROR :GL_INVALID_OPERATION : glDrawElements: Source and destination textures of the draw are the same.
This error pops up after between 2 and 3 animation frame requests, depending on whether I've refreshed or hard refreshed the screen - and even then the timing of the error is not consistent. A hard refresh may occasionally delay the error from showing up until after 3 frame requests, but most of the time for both a refresh and hard refresh the error shows up after 2 frame requests. Based on those observations, the problem seems to be in an asynchronous component. I also have a simpler toy version of this loop running without any errors. I've been simplifying the buggy program more and more (it's now just displaying a non-moving cube) and still can't find the source of the problem.
The program is decently complex, so it's hard to determine what code to show here, so instead I'm hoping for an answer that may teach me a little about approaching a problem like this generally, so I can apply it whenever I hit similar situations: My question is, what are the top candidate areas in a program for a problem like this? Knowing that, I can focus my efforts.
I hope this makes sense - let me know if you need further clarification. Thanks!
Update:
This seems quite basic, but I will add that when I put no objects in the scene (cubes, axis helpers, etc.) and leave everything else the same, the error goes away.
Also, I'm wondering if this sort of error can occur because of a lost context? Like so.
You probably need to post your code but just guessing...
First off the error is exactly what it says it is. You have a texture attached to the current framebuffer. That same texture is also assigned to some texture unit.
Why that happens intermittently I can only guess. If you're loading textures from images or even from dataURLs they load async. Being in the cache or if you're testing locally they'll load quickly. So, my guess would be you're not correctly setting your texture units every frame (calling gl.activeTexture and gl.bindTexture for each texture unit used by your shaders). When your image is finally downloaded async you call gl.bindTexture to upload the texture. That ends up assigning a texture to whatever the current active texture unit is and messes up your setup.
I have been making a simple website with AngularJS and D3JS and created a custom circle mesh library (very crude). It all works fine in Firefox but it doesn't work in Chrome. The website is up at petoknm.github.io . In my homepage I have this circle mesh thing that displays the circles. But when I transition (directly) to another page with this circle mesh (programmming page) it starts behaving differently. And when I go from programming to home it starts to ignore the clipPath on the first two images (two probably because of the two images in the programming page). The svg is identical (I checked only the first three 'a' tags with the images and the first three clipPaths) to the correct svg that was there first... I don't know what happens.
This is a screenshot just after first loading the page
http://i.stack.imgur.com/2fAI6.png
This is a screenshot after coming from the programming page
http://i.stack.imgur.com/JLO3r.png
As you can see the clipPath is still in the svg and "shown" by Chrome but is not actually used (or is ignored).
Please help, I have no idea why it happens and why it's no problem for Firefox
I'll make an educated guess and say it's because your programming page is reusing ids "#clippath0" and "#clippath1". Because it's a single page site and you are replacing the parts of the DOM that contain those references, perhaps there is a bug in Chrome where it getting confused over what they point to.
Try using different sets of ids for each page and see if that fixes it. Maybe you could add different prefixes for each page (eg "#homeclippath0" and "#programmingclippath0").
It does seem like a bug in Chrome though. Perhaps you might want to report it.
I am having some trouble with scaling and rotation of SVG images with FabricJS.
I've been working on an icon builder for my website. A user can add layers, select a shape for that layer, then set a number of options such as coloring and stroke width. I populate the possible "shapes" and, for maximum flexibility in the shape's complexity, I am using SVG files that I have created with Inkscape. I use the loadSVGFromURL functionality in FabricJS to handle loading the file onto my canvas.
The problem is when I load some (seems to be most) of these SVGs to the canvas then try to use the handles to scale and rotate the image, the rendered result is not appearing as expected: Octagon SVG Image and Action Results.
On that image, don't worry about the "sliced" edges, that's just the editor's boundaries. After loading my octogon.svg to the canvas, it looks right. When I rotate, it gets messed up. I rotated to the right and downward and the image moved to the left and upward. Then, when I scale, it moves vertically the opposite direction.
I have tried programmatically changing these settings and it behaves the same way. I've read several posted questions here and on newsgroup discussions, but nothing got me a solid solution.
One very close solution was using an optimization tool to remove some transformation data that is apparently not liked much by fabric (that tool being found here http://petercollingridge.appspot.com/). It seemed to work, but not for every image, this one included. In fact, regardless of the optimization options I chose, the tool altered the octagon so much, it wasn't really usable as an octogon. That tool is also reference in this existing question: 10470508 (issue-with-svg-display-rendering-in-fabric-js)
I have saved the SVG out of Inkscape in various formats: Inkscape SVG, plain SVG, and Optimized SVG - none made any difference. I also tried Simplifying the Path prior to exporting in all of these formats - again, no difference (though for some shapes, this did seem to work).
I have read many bugs and the related discussions on GitHub with Kangax involved and tried things like the centeredRotation property and origin points on the objects.
I noticed that Inkscape's x,y of 0,0 is the bottom left corner which I thought was a little odd and thought maybe that had something to do with the scaling at least. To attempt fixing it from that point of view, I set flipY on the object, but that didn't work at all. It appeared very far above the editor panel. It almost feels like the transform point is somewhere way above the bounding box. But I cannot verify that. All the settings I check seem like they are set correctly.
I did try a hexagon made in Illustrator and it seemed to work, but I do not have Illustrator at my disposal and to say that is a "solution" is somewhat undesirable. Perhaps this is better logged as a bug, but with all the related chatter, I am somewhat hoping that it is resolved and I just have not found the right combination of settings or processes to follow. I really need to be able to use Inkscape for these. Kangax has pointed out that Inkscape SVGs are more troublesome for FabricJS, but he goes on to say they are getting better. So perhaps this can help with another step forward.
I have also reviewed the code itself on GitHub, but cannot seem to pin point what exactly I would need to change to fix this; though, I am not really sure where the point of failure is - fabric, my settings, or my SVG file.
UPDATE 2/21/2014 10:27PM EST
I began digging into the SVG file structure, comparing the ones giving me trouble with the ones that are working. It definitely does seem like the problem is due to a "transform" attribute being present on a path, container, or other object tag. The optimization processes I've tried should have removed them, but I still have not found a solid solution that just works in all cases. I'll keep you updated.
I don't know much about fabricjs and Inkscape, but using the svg DOM the following will apply for rotation and scale transformations applied individually to an element: Maybe you can apply this. If you want to rotate+scale an element your can append the transformation strings or use transformation matrix. Hope this helps
var bb=elem.getBBox()
var bbx=bb.x
var bby=bb.y
var bbw=bb.width
var bbh=bb.height
var cx=bbx+.5*bbw
var cy=bby+.5*bbh
//----rotate from center of elem---
elem.setAttribute("transform","rotate(angle "+cx+" "+cy+")")
//---scale: translate center to(0,0)+scale+translate back---
elem.setAttribute("transform","translate("+cx+" "+cy+")scale(myScale)translate("+(-cx)+" "+(-cy+")")
Would it be advantageous to load your svg files as xml using XMLHttpRequest? You could then treat them as xml, work on them, then insert them as SVG by cloning them.
pretty seamless, I think. You can extract elements from XMLdoc and insert them as svg by merely cloning them. Also you can include a DIV in your html and dump the entire xml response text into it as its innerHTML. Then everything is available for DOM workings.
var XMLdoc
function loadSVGasXML()
{
var SVGFile="my.svg"
var loadXML = new XMLHttpRequest;
function handler()
{
if(loadXML.readyState == 4 && loadXML.status == 200)
{
//---responseText---
var xmlString=loadXML.responseText
//---mySVGDiv.innerHTML=xmlString ---
//---DOMParser---
var parser = new DOMParser();
XMLdoc=parser.parseFromString(xmlString,"text/xml").documentElement ;
}
}
if (loadXML != null)
{
loadXML.open("GET", SVGFile, true);
loadXML.onreadystatechange = handler;
loadXML.send();
}
}
Like the other issues posted about this, the problem was still in the individual transformations on the paths. The online solutions I found never worked as well as I needed them to; at least not with SVGs from InkScape. Saving the SVG in a different type right out of InkScape also did not impact the end result. Some shapes, when "simplified", were fine; however, it was not consistent enough. So, I set out to develop a solution.
After reading SVG file structure documentation, I created this specifically to handle InkScape SVGs. Some SVG commands are not handled, but so far, I have not noticed an issue with the few missing commands (which were excluded simply due to time).
EvilEye Games - InkScape SVG Transform Remover
In the end though, I just decided to use some free SVGs from another website. So it was all for not for me. However, I was able to figure it out and fix the problem. So figured maybe this would come in handy for someone else. Its not perfect, but it does what it needs to.
I wrote this Mandelbrot plotter in HTML5 and it has a reproducible performance bug that I can't figure out.
In the Plot Controls section, there's the ability to save coordinates into a pick list to be able to return directly there later. If I select a saved set of coordinates, however, and then click "Load", the performance suddenly becomes so slow that at first I thought it was hanging the script (it will eventually start to develop the image as it's supposed to).
I cannot figure out why. The onclick handler for the Load button (line #258) simply calls gotoCoord() (line #457). The gotoCoord function simply sets several of the plot parameters (xOff, yOff, fMag) and then calls initDisplay(). I do those exact things in several other places with no ill effects (mousedown on line 124, zoomOut on line 386, zoomIn on line 394). I can't figure out what's different about gotoCoord.
I've done repeated comparison testing, navigating to a plot and timing how long it takes to develop the image. Then I save the coords and load them. The performance hit is drastic.
Does anyone else see what I'm missing?
This question is answered, so just taking it out of the unanswered list.
#DCoder's comment solved it. The plot parameters are stored in localStorage and the pick list is loaded from there. Of course, when loading from localStorage, the values will all be strings. That's what was different about gotoCoord from the other functions. Since the parameters are used in the plot (lines 589 and 590), the text must be converted to a number for each calculation of each pixel in each frame!
Three little plus signs fixed it.
I started a web based game engine a while back, but used primarily jQuery to handle the sprites and animation, now I am learning the power of HTML5, by moving the game canvas to HTML5. So here's issue I am having: I'm using multple canvas as suggested from http://html5.litten.com/layers/canvaslayers.html to layer images.
This is not working for me, even if I set z-index to 999999: Here's my code->
http://snipt.org/xoKn
The objects layer is not on top of the tiles, thanks!
The code should work (at least the canvas handling part). I looked at your script and there may be the problem with loading images. You have
var tile = new Image();
tile.src = tiles[i]['bg'];
tilesCtx.drawImage(tile, tiles[i]['col']*32, tiles[i]['row']*32);
but it won't work since image is not loaded yet. Instead you should use
tile.onload = function(){
tilesCtx.drawImage(tile, tiles[i]['col']*32, tiles[i]['row']*32);
}
or something like that (i.e. you won't have a reference to the i variable so it needs to be modified).
Note that in the tutorial they use setInterval(drawAll, 20); which makes it work after a while (since after a time all images will be loaded).
Of course you may lose ordering of images (although this does not seem to be important), so preloading all images at the begining and then drawing them all at once is a good idea. Give it a try and let us now if it works!
If anyone is having a similar problem I managed to solve this by loading the first layer first then the lowest layer last. Apparently it seems that whatever is loaded first will be on top.
So my solution was to just move m objects loop above my tiles loop. Interesting to me, had no idea it mattered what loads first.