• Content Count

  • Joined

  • Last visited

About ZackMFleischman

  • Rank

Contact Methods

  • Twitter

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Deltakosh Would you mind sharing a bit more insight as to the Decal algorithm? I might like to modify it to only create the triangles of the decal mesh whose normal is within a certain range of the normal at the pick point. (by means of the angle between them) I guess I could also "transparent out" the non-desired triangles as well. For my use case I don't always have the luxury of knowing what every mesh is, and even then there are some meshes that just don't work by tweaking the decal size, because they're too rounded and sharp at some points so culling the volume on the Z-Axis produces undesired cropping of the decal, but they're thin at other points so it would bleed through. Thanks for your input, Zack
  2. Hey all! So I noticed some behavior where a decal was "bleeding through" (or duplicating itself) through the thinner parts of models. The behavior is witnessed in the standard decal playground if you try to put a decal on the feet of the cat: (See the attached images for an example) I've already read pretty extensively through the Decal's thread: From that thread I gleamed that I can mitigate this slightly by limiting the Z scale on the decal size. However this is far from ideal as I'm painting decals on arbitrary meshes, many of which have several bends and/or are very thin, so it very much seems like I have the trade off of not letting my decal bleed through to the other side of a mesh with unnecessarily clipping it around corners < 90. I can appreciate that there is some difficulty getting the decal's to behave appropriately when wrapped past 90 degrees, but does anyone with some knowledge of the behemoth that is the decal implementation have insight to how we can at least correct this duplication / bleed through issue? Thanks! Zack
  3. @Vousk-prod. This is by design. The black drawing is actually 2 "impact" images overlaid on each other. I chose it because it has transparency. Thinking back I probably should have chosen 2 different images but I was just hacking something up to demonstrate the point. If you click the image on the left it turns red, if you click the image on the right it turns blue. This includes the parts of the images that overlap.
  4. @fenomas @Deltakosh @Pryme8 Thanks guys! For testing whether a part of an image is transparent I ended up doing as @fenomas and @Deltakosh said and did the following: Created an offscreen canvas element with a 2D context and draw the image to it. Get the Image Data via `context.getImageData` and thus get access to the raw pixel data. For only picking meshes when I've picked a non-transparent area of the mesh I did a pick loop as suggested: Pick with all meshes set to `isPickable`. Test the UV coordinates of the texture of the pickedMesh to see if it's transparent. (via `pickInfo.getTextureCoordinates`) If it's transparent, mark that mesh's `isPickable` to false and recurse. Eventually we reach a mesh that isn't transparent at the picked point, or there is no mesh. We set `isPickable` back to true for all the ones we flipped and return that pickInfo. You can see the results in the playground here: If you click the image on the left, the background will turn red. If you click the image on the right, the background will turn blue. If you click the background (including in the middle of the images where it's transparent!) the background will turn back to green. Thanks again for your help. Big fan of this community.
  5. @NasimiAsl If a GPU Picking system would help I'm not opposed to it, but I don't know of one that exists or what that would entail. As far as reading the pixel from the rendered result, I'm referring to reading the color data from a Texture at a UV coordinate in the range (u=[0,1], v=[0,1]). Whether or not the texture is rendered is irrelevant. I want to know what it's color is at certain coordinates. I'm surprised that I can't just access a 2D array like this: textureObject.colorData[v]. @Pryme8 Yes, that is the algorithm I described above. I believe I could accomplish that if I were able to check the alpha at the meshes uv...BUT I don't know HOW to check that alpha value (as I've mentioned a few times now). HOWEVER, this algorithm seems terribly inefficient due to multiple picks on the order of the number of meshes the cast ray would intersect. I feel like there is a way to construct an algorithm that should only have to execute the picking process once, and I'm open to any ideas people might have towards this. Thanks again guys. (ps, no idea why this underlined everything but I can't turn it off with an edit)
  6. I appreciate you taking some time @NasimiAsl but I'm not asking how to ignore a mesh that has transparency. For clarity, I'm asking 2 things: 1.) How do you ignore ONLY the completely transparent part of a mesh when picking? 2.) How do you get the RGBA color of a texture given a specific UV coordinate into the texture?
  7. Hi! So I'm ultimately trying to pick some meshes with textures that have transparency, but when they overlap, the transparent parts of the mesh still get picked. Playground: If you open up the console in the playground and click the 2 black circles in the center of the overlapping "impact" textures, you'll notice that it always picks the 1st texture (although you're clicking on 2 separate "visible" textures if you take transparency into account). I thought perhaps I could test to see if the texture color at the UV coordinates of the picked mesh is transparent, and if it was, I could temporarily mark that mesh as not pickable and pick again at the same location to get the mesh under it until I got something that isn't transparent (and then restore the isPickable state of everything). I still think that could work (although it seems terribly inefficient as I have to do several picks unnecessarily), but I frustratingly can't actually find a good way to get the texture color given the texture and some UV indices (obtained through the pickedInfo). Am I just missing something obvious? Is there not simply an analogous textureObject.getTextureColorAtUV(u, v) function? I'm also open to other suggestions to get more accurate picking with transparency taken into account. Thanks so much! Zack
  8. Lol, just seeing this now. Fortunately still very relevant!! Ohhhh renderTargetTexture is nifty! I think that will do nicely! Thank you
  9. Hi! So I want to have a mini-me view of a mesh that will always be present in a little bubble in the lower left of my screen. I figured the best way to do that is to have two active cameras. One is my regular camera as per usual, and the other is in a small viewport in the lower left with a layer mask that filters out everything except an extra instance of my mesh. However, I'm noticing some strange behavior where only the first active camera will actually show the mesh and the instance. That is to say, I create the instance, and all is well, but then I push the new camera on the active cameras array and the new camera does not see either the mesh or the instance. If I switch the order of the active cameras (that is to say us unshift instead of push on the activeCameras), then the mesh and it's instance are both visible in the new camera, but not the old. Do any of you have insight to how mesh instances work with cameras? I assumed it would be the same, but there seems to be some magic going on. Thanks.