In response to Kumorii
Kumorii wrote:

This is my biggest problem with it, too. I made a feature request regarding it awhile back but IIRC it was deemed not feasible. You could make a workaround by adding a cutout lighting overlay for everything you want to ignore the lighting, but that's a lot of overhead for a small feature.

Besides that, every time something crosses in front of the cut-out it looks all funky.

In response to Bravo1
DarkCampainger's lighting system is more comprehensive, compared to mine. His actually has shadows correctly cast on walls and mobs that blows my mind and I have no idea how he does it so quickly and smoothly.

My lighting system isn't capable of that; so while I can have light spilling out of windows and stuff casting shadows, it only sort of pretends to be correct. For example, if I put a tree between a chest and a lightsource, the chest won't be affected by the tree's shadow and will still look fully lit. Screenshot. I don't know how I want to go about implementing light occlusions without ruining performance.

The way my lighting can have objects that ignores light has to do with how I've arranged the planes in my lighting system. Turfs or anything with no perceived height, like grass, go on the TURF_PLANE. The TURF_PLANE's plane_master is then set to BLEND_MULTIPLY. Beneath the TURF_PLANE, you have lights and shadows and ambient light. Any object that can ignore light or has a perceivable height is placed on the OBJ_PLANE, which is above the TURF_PLANE.

These objects have a function that computes their lighting and, if appropriate, shades them. Objects can have either flat shading (changing atom.color) or detailed shading (with a normal map) or no shading (full brightness).
Another way for an object to ignore light is to give it a white overlay on the lighting plane. It effectively becomes self-lit.
In response to Lummox JR
Lummox JR wrote:
Another way for an object to ignore light is to give it a white overlay on the lighting plane. It effectively becomes self-lit.

This is what Kumorii is essentially suggesting for Bravo1 to do. Bravo1 is saying that since the lighting plane is above the objects, this white overlay will sometimes intersect with other objects that have a higher layer than the object that is self-lit.

The solution here is to give nearly everything an overlay. These overlays MUST have a layer blow the usual lightsources, but also must be in the same plane as lights, and these overlays have to be on BLEND_DEFAULT. These overlays must also be in roughly the same order, layer wise, as the objects that they belong to. For objects that ignore lighting, these overlays must be white. For objects that do not ignore lighting, the overlays must be black.
In response to D4RK3 54B3R
D4RK3 54B3R wrote:
[...] The solution here is to give nearly everything an overlay. These overlays MUST have a layer blow the usual lightsources, but also must be in the same plane as lights, and these overlays have to be on BLEND_DEFAULT. These overlays must also be in roughly the same order, layer wise, as the objects that they belong to. For objects that ignore lighting, these overlays must be white. For objects that do not ignore lighting, the overlays must be black.

Which is still a lot of effort and overhead to put into such a trivial feature.
In response to Kumorii
Kumorii wrote:
D4RK3 54B3R wrote:
[...] The solution here is to give nearly everything an overlay. These overlays MUST have a layer blow the usual lightsources, but also must be in the same plane as lights, and these overlays have to be on BLEND_DEFAULT. These overlays must also be in roughly the same order, layer wise, as the objects that they belong to. For objects that ignore lighting, these overlays must be white. For objects that do not ignore lighting, the overlays must be black.

Which is still a lot of effort and overhead to put into such a trivial feature.

I wonder if it could be built in to generate lighting in that fashion. It's not so much asking to avoid planes, but to create a special lighting plane and then have everything create a mask for that plane. Then the mask could be turned on/off, the icon could be changed for it to make light sources, size, etc.

Would be interesting to see at least.
I've been MIA for a bit, but I'm back (for now)!



I should probably work on a better cast animation.
In response to Kumorii
I actually ran into the exact same masking problem when creating the lighting system for my game, where I needed to have a black mask overlay on everything or you would have weird effects when things went behind one another.

In my system, every lit object has a mask overlay, and any number of lightmap overlays. The mask overlay is just black on BLEND_DEFAULT, but the lightmap overlays are BLEND_ADD'd.
Then the plane that contains these lightmap and mask overlays is set to BLEND_MULTIPLY.

To give you an idea of what I'm talking about, here's a screenshot that shows the lightmaps. It's fundamentally the same as having a white mask overlay for ignoring lighting.

For comparison, here's a screenshot of the same location with how it normally looks.

Playtesters thus far have reported good performance in multiplayer and in singleplayer, so I don't think it's that bad in terms of the performance hit.
I don't think it's that much additional effort, since it's literally just an appearance with the same icon, the same layer, and a color matrix.

So, I think having mask overlays for everything is worthwhile.
In response to Bl4ck Adam
Ooh pretty effects. You should try putting the glowy part of all of the fire particles and of the fireball itself on BLEND_ADD.

For additional juice you could make the fireball leave behind a trail of fiery sparks and/or smoke :)
In response to D4RK3 54B3R
I'll have to make the glowy parts separate, but I'll definitely look into that. Thanks! :O

EDIT: With the blend modes:



It looks AWESOME, thanks!
In response to Bl4ck Adam
Looking good! :)

Try giving the fireball some more oomph.
When it hits the barrel, make it push the barrel a little.
And when it hits the wall, make the impact more violent: make the sparks that come out faster, maybe have bits of rock flying off, and add some spark particles that travel in the opposite direction of the fireball (like negative of the fireball's velocity).
In response to Bl4ck Adam
Those are some darn sexy particle effects.

this is pre glow etc, a whole lot of trial and error put into it
Fireball battle!!
In response to Ishuri
I'll mess around with a few things and see what I can cook up :)

Just got off of work, else I would have replied sooner!
In response to Kumorii
Kumorii wrote:
Bravo1 wrote:
Kumorii wrote:
Flick wrote:
I haven't really messed with plane based lighting yet. Is there a reason able way to do indoor / outdoor lighting for multiplayer? Walls blocking light, spilling out windows, etc.

I haven't done it(nor would I really know exactly where to begin) but it is possible as I've seen screenshots of it. I think D4RK3 was the one who posted them. The plane lighting stuff is awesome although somewhat confusing.

Exactly. The main issue I have with plane lighting is that you can't really have objects that ignore the lighting without them being on a higher plane, and as a result, appearing above objects on the map.

D4RK3's got something that seems to pull this off, but I'm not exactly sure how.

This is my biggest problem with it, too. I made a feature request regarding it awhile back but IIRC it was deemed not feasible. You could make a workaround by adding a cutout lighting overlay for everything you want to ignore the lighting, but that's a lot of overhead for a small feature.

You guys are rubbing your heads about how lighting works and im just sitting here trying to figure out wtf a pane, scene and stage is :/.
Severed World BETA TESTING is near:

http://www.byond.com/forum/?post=2069288


Fluffed up the glow a bit more. Quick question: Should the particles consist of client side images or /Particle objects [as far as efficiency is concerned]?
In response to Bl4ck Adam
I setup everything as client side images.
Yut Put wrote:
iirc you cant animate () or flick () images which makes them unusable for visual effects but i might be wrong about the animate bit

you can animate images, and as a trick to flick(), simply set the icon state in the icon file to loop from indefinitely to 1, so that when u set it's icon_state, it flicks it rather than plays endlessly.
Page: 1 2 3 ... 181 182 183 184 185 ... 349 350 351