Not sure what's causing this, but normal maps lit at certain angles don't seem to like having transparent pixels. If you move the mouse to the corners (or beyond) in the example .cap, you'll see it pretty strongly. It seems to happen closer to the source at lower Z angles, so I could circumvent it by increasing the Z height depending on XY distance, which would actually be a nice 3D effect... but I'm still curious if this is a bug, something I've done wrong, or just inherent.
I guess I should also say that light positions can't be checked at runtime, otherwise it would be easier to investigate. In the end, there are ways around it, including just not using transparency; it's just weird and undesirable; if there's some solution, that would be awesome.
it's the tint plus
take is off and it doesn't do it anymore
if you're intent on using the tintplus, a workaround would be to have copies of the objects in the exact same spots with the mask effect on, that would make those parts invisible, but you'd have to have them on a separate layer from other objects that might move into the small mask area
btw, I like the look of it, what did you use to generate the bumpmap?
It still does it even with just the 'bumpmapping' effect.
I created the normal map the same way any other normal map for a 3D model is created: baked from a highpoly model to a low, in this case just a plane. Thanks, I am interested in seeing how normal maps can be used in a 2D game... if only transparency were fully functional, you know?
And thanks again! Mask object, that's what I was looking for. It wasn't opacity, wasn't alpha testing... masking, duh.
Uh... how's the mask effect work? It must be something completely counterintuitive; I think I've tried every combination of white, black, transparency and 'activate mask'.
edit: Nevermind, got it. Didn't even need a mask effect object, just had to enable 'force own texture' on the layer. Success!
Doing some other tests, I find it can be used to create a cool sort of 'wash' effect over isolated objects - since the light is a point light after all, not directional...
I think that's where I misunderstood.
im not at home, on a short break at work, viewing this from my cell phone, but you can sort of simulate a directional light with masking
search forum for the word bumpy
and check out my bumpy light cone for an example of fake directional lighting.
cant check out your caps on my cell though
ill check those later today
Thanks lucid, and nice example, but it's actually not at all what I meant.
Still no answer on whether or not this is something that can be fixed, the transparency not staying transparent at a certain combination of values, I will instead ask, is it possible to create a game with collision detection and interaction between objects, basically a normal game, with every sprite (or group of non-overlapping sprites) on its own layer? Seems like the only way to have a fully normal mapped game at this point.
If it's nothing to the engine so long as layer orders are correct, I guess that's fine, even if it means creating a new layer for each character, every branch of a tree.
I guess I've never tried to use an alpha masked bumpmap before
I hope I'm not being rude to anyone here. The lack of response is sort of troubling. Thanks again for all your suggestions lucid. Maybe you're familiar with this new problem now? Sorry to be so full of questions... but since Construct is still mostly undocumented and in beta, I don't see the harm in putting problems out there. Maybe I'm not getting much of a response because this is in Uploads rather then Tech Support...
I've decided, for the sake of greater visuals and better performance, to bake all the dynamic lighting to canvas at the start of every level. Everything was going beautifully, until I found that canvas objects cannot be anything other than the screen resolution when dropping these sort of effects to them. (If this isn't a known fact, just try resizing one of the canvas objects in this cap and running it.) This was fine, I just resized the level and did an array past of canvases. Easy.
However, it's only baking to the first two... I wonder why?
Edit: This is interesting - if I set the layer's zoom (before running/compiling) so that it will all fit on the screen, it catches everything. If any bit of the third canvas object is off screen at startup, it ditches the whole thing. I guess I could start zoomed way out and just set it to zoom back in at the end of baking... but I have no idea how to check if it's done. Setting it to zoom back in at the press of a button when I can see that it's loaded completely works.
Edit2: Got it. With Layer 2 set to 1% zoom in the editor, set it back to 100 with an Else + Trigger once beneath the "for each" event... apparently posting a question gives me a boost to figure it out on my own real quick. /eyeroll
I don't see the effect. :s
Then again, it seems my computer has issues with Canvas
Yeah, they seem almost unpredictable. I messed with my layout width some more and wound up with nothing again. Or it would bake to the second canvas but zoomed out to 100% whereas the rest of the layer was at 10%... that and it just takes forever to render out more than three canvases (and it doesn't even work in the end).
The confusion this causes is discouraging, so I guess it's time to take a break. And either completely redesign what I had in mind for level size or just scrap this method entirely.
Or, you know, just not use normal maps. There's got to be a more efficient way to generate this sort of static imagery at runtime though, will just have to figure it out I guess.
Sucks that your computer can't run it, that's pretty weird. I got a 3x2 level working, which I think is more than enough to create a small prototype/demo game in. If I want to do a larger project, I'll just stick to a flat graphical style; it's probably my own fault for trying to make Construct do things it wasn't meant to do. No hard feelings, in the end.
Develop games in your browser. Powerful, performant & highly capable.
actually, I think it is partially because it's in uploads instead of help
this community actually gets complimented on it's responsiveness/helpfulness all the time
if you find you're not getting any responses even in the help section
it's usually a bug you're reporting and you can just report it to the bug tracker
I actually can't say anything too helpful at the moment, because I'm a little busy
but I will say this for you to take into consideration, and maybe it will help
the canvas takes up vram like a sprite, so if you make the canvas the size of the screen, it will be like trying to have a full screen sprite. if you have several, it will probably run on your or my machine, but not on a lot of others
also, I could be wrong because I thought I had taken care of it before, but it really seems to be working
I filled in the transparent areas of your bamboo normal map with black
I know that's not how normal maps are supposed to work
but try this :
I haven't looked in detail what the separate normal maps are for, but the far right one is still doing it, but none of the other bamboo sticks, I can't get the glitch to show up.
as for the other weird canvas issues, I'll have to have a look at those tomorrow maybe.
The glitch isn't going to show up in that .cap because force own texture is enabled on the layer; the far right column is just a way to see what the normal maps are doing, and it (intentionally) will show the transparency bug even with that setting enabled. Also, with the first (yellow-tinted) normal map, the black definitely seemed promising at first, but essentially you just turned it off. Turning up the intensity makes it come back.
I'm basically using two normal maps here, the second one the inverse direction of the first one, so that I can control shadow/ambient color as well as the color of the "light". I thought it would be cool for a scaling daytime effect, even in the case of when I was dropping the effect to canvases. (In that case, I would simply set up the atmosphere and daylight before loading.)
Weird that canvases don't work with these things at any resolution other than full screen then; that is the only way I could get them to paste the normal map effects without offsetting them inexplicably. Even if it's just a little bit off proportion of the screen, it messes up.
I can see this working for a smaller-level'd game then, that's at a low resolution and only one screen per room... as it is I'm not set on making a game that uses many canvases or uses lots of realtime bumpmapping, these are however bug-like behaviours I have encountered, though like many others who do receive response in this section I am simply not sure if they are, in fact, fixable bugs, or not. There are always ways to work around them!
Thanks for looking at this with me; I think perhaps the main problem here is that Construct's use of normal maps is intended to be minimal, and I'm trying to make a graphically intensive game with it; it's a shame this doesn't really work as expected, but you know, I can just as easily create a game with raster graphics, all baked lighting, and if it means more people will be able to play it (seems common for people here to have outdated hardware?) then I guess that's fine.
it's probably better to write a special shader for the effect you want, since it's very specific and hard to emulate using existing effects.