Lighting

If I have local lighting turned off in graphics preferences, is it correct to say that the only way I can have lights inside my home is to use scripted lights?

If you want the lights to turn on and off, yes. Otherwise, just select each prim you are using as a light source (a light bulb, maybe?), then go to the Textures tab in your Edit menu and check the Full Bright box. That will make the prim shine. You can give it more oomph by increasing the Glow factor as well.

If you have local lights off, you are pretty much limited to using full bright on the items you want to see. Scripting won't make local lights render, if they are off they are off.

vertex shader glow

Glow isn't even available on a lot of the older cards that have trouble coping with local light.

Good texturing can go a long way toward making a place look lit, even when it's not. Set all surfaces to fullbright, to eliminate all effects of actual light in the room, and then apply texturing with faux lighting baked into it. If you make the textures well, the illusion can be 100% convincing.

Take a look at this video for an example: http://www.filmingpathstudios.com/2007/04/15/chapel-of-y-ule/

Yes, that was filmed in SL, and no, there are no actual lights in the scene at all. The entire build is fullbright, and all the apparent lighting and shading is just clever use of texturing.

Thank you everyone, this has been so helpful! Yes I think the "full bright" option is what I was looking for - I've seen lights in other buildings that worked, so I knew there must be a way to get it to render even if I have local lighting turned off.

Chosen, thanks for the video - that build is amazing! Okay... now I'm off to wrestle with textures lol

That method does produce impressive results, but it also uses an incredible number of textures. My own first attempt at such a build ended half way through when my frame rate began falling so low that I could hardly continue working. I realized that even if I could complete the build it would be worthless for anything but bragging rights due to the excessive demands it would place on any visitors computer.

It doesn't have to use "an incredible amount". It depends on the build, of course, but there are several methods to reduce the total amount of textures you need:

1. Repeat textures as much as possible. For a simple example, if your light source is centrally located in square room, then you can repeat the same texture on each wall.

2. You can use an unlit base texture, and then overlay it with a translucent shadow prim. There's a bit of a trade-off here since transparent textures take longer to render than non-transparent ones, and of course you're using extra prims. But if it's a difference of, say, 50 unique fully baked textures vs. just a small handful of unique base textures and a couple of unique shadow textures, it's better to go with to go with the overlays.

3. You can save on load time, and on network traffic, by combining several textures onto a single canvas, and then using the repeat and offset settings to display just one portion of the canvas on each surface.

4. As always, keep textures small. Remember, you can use sixteen 256x256's, or sixty-four 128x128's, for the memory cost of a single 1024x1024. Or better yet, if you're going to use all those in one scene, mount the whole lot onto just one 1024x1024 canvas.


Being smart about baked lighting is just like being smart about everything else. It's certainly possible to do a gorgeous bake while still keeping the texture demands light.

You will notice, however, that even in the link that you posted it states 1GB of textures were used for just that piece of what was to be a larger structure. I would guess that is a missquote, exaggeration, or is not taking jpg compression into account but even if the true number is just 100MB it is still far too texture heavy to be practical.

That's because every single surface in that build has a unique 1024x1024 texture on it. It was one of that particular artist's first experiments with high quality baked lighting for SL, and he did go a little overboard with the sizing. Very nearly the same level of apparent visual quality could be achieved with 256x256's and 128x128's, and then the memory usage would be somewhere between 1/16 and 1/64 of what it is now. Further, there are many places where textures could have been repeated, but weren't.

That build was never anything more than a proof of concept. Optimization was not a concern in that respect. For an optimized version, you could do the same chapel with 10-20 megabytes worth of textures, or maybe even less, and it would look just great.

In some cases, by the way, the visual quality will actually be better with smaller sized textures than with larger ones. Often when baking, it's good practice to start by rendering your textures at 1024x1024, and then downsize them in post before you apply them. This helps to clean up light-bleed, and minimizes the impact of certain common rendering artifacts.


Compression is not a part of the equation. What's relevant is active consumption of video memory, which is a function of the actual pixels in each texture. Compression is a function of file storage, which has nothing to do with that. For more information on this, see the sticky at the top of the texturing forum.

It certainly is for me since I would have to stand in the middle of the build for 24-48 hours before 1GB of textures could load.

Jamay, you're still not getting it. You really, really, really need to read that sticky I mentioned. Right now you're looking at it bass ackwards. I'll explain.

When it says "1GB worth of textures", it's talking about video memory, not file size. Every 1024x1024 sized texture will always consume precisely 3MB (without transparency) or precisely 4MB (with transparency) worth of video memory. This is true whether the file that contains the image is compressed or not. As far as your video card is concerned, a pixel is a pixel is a pixel, and there's no such thing as compression.

But video memory has nothing to do with "load time" in SL. "Loading" in that context is all about file size, which is a completely different thing.

All images in SL are stored as JPEG2000 files, which are heavily compressed. While a 1024x1024 sized 24-bit texture will always use exactly 3MB worth of video memory, the JPEG2000 file that contains it will usually only need to be a couple hundred kilobytes or so for its file size. And it's just that couple hundred K you're waiting for when a texture is "loading", not the three megabytes.

Take 250-300 textures, at 1024x1024 pixels, and that's your gigabyte of video memory right there. But again, video memory is not the relevant factor when we're talking about "load time" in SL. What you're actually waiting for while textures are "loading" is the files to be transferred from the SL servers to your local machine, not for the pixels to load into your video buffer. The former takes several seconds to several minutes for each file, while the latter only takes a few nanoseconds for each image.

Since the files are compressed, they are considerably smaller than their contained images' video memory consumption requirements. That "one gigabyte" is only going to be somewhere around 1/10 or so of that, roughly a hundred megabytes, when you put it in terms of JPEG2000 file size. This is why I said compression was not part of the equation for what we were discussing in our last round. That part if the conversation was all about video memory, not about file size at all.

Of course, after the files "load", and you've got a gigabyte worth of pixels in active memory to contend with, your frame rate is of course going to drop. But that's a separate issue altogether from whatever amount of time the loading itself might have taken. And since loading is all you seem to be concerned about, that's a non-issue for this particular discussion.

And the whole thing is really a non-issue anyway, since the fact is you should NEVER put a gigabyte worth of textures in your scene anyway. As I said, that chapel was simply a proof of concept. It was not optimized at all. Again, it could be redone with just a tiny fraction of its original texture weight, and look just as good, if not better.




Oh, and incidentally, if it really takes you 24-48 hours to download a gigabyte worth of data, that means your connection speed is only somewhere between 48 and 96 Kbps. That's dial-up speed, not broadband. You do realize you shouldn't be using SL on dial-up, right? A broadband connection is a requirement.

I'm guessing that you're not actually on dial-up, and that your connection is probably a respectable speed, or you wouldn't be here. Perhaps you're basing your "24-48 hour" estimate on previous experiences with downloading torrents of that size. Those can absolutely take that long, even if you've got the world's fastest Internet connection. But that's only because torrent traffic works differently than other things. If you were to download a gigabyte of data directly from a Web server, you'd get the whole thing in anywhere from a few minutes to a few hours, depending on your connection.

Assuming ideal conditions, here's how long it should take you to download a gigabyte at various connection speeds:

96 Kbps (dial-up): ~24 hours
500 Kbps (typical DSL): ~4 hours and 40 minutes
5 Mbps (typical cable or FiOS): ~28 minutes
15 Mbps (better cable): ~9 minutes
35 Mbps (high end cable): ~4 minutes
50 Mbps (FiOS's claimed top speed): ~2.7 minutes

If it really takes you 24 hours or more to download a (non-torrent) gigabyte of data from a typical Web server, I'd highly recommend you start shopping for new ISP immediately.

As far as download speeds go, around here the fastest offered is advertised at 64kbs. That number is a lie. Between 2am and 6am I can occasionally reach 49kbs, but for the rest of the day speeds do not go over 38 kbs. With an average speed of 30-35 kbs, 'load' (download) time is indeed a major concern for me. One of these days maybe Ill be able to pay the installation fee and bribes needed to get a commercial line installed that runs somewhere near the speeds everyone else is used to.

I fully understand how pixels work.

Wow, really? Sorry to hear that. I hate to say it, but if that's really true, then you shouldn't be using SL. Not only are you lagging yourself every time you log in, you're also lagging everyone else around you. SL simply isn't meant for dial-up speeds.


Great. Now apply that knowledge to the difference between pixels and files, and you'll realize why a gigabyte of texture data does not have to be a gigabyte worth of files.

But I guess it doesn't really matter if all you've got to work with are dial-up level speeds. It's going to take you forever and a day to download much of anything. Once again, sorry to hear things are so difficult where you are.

Really Chosen, curious how exactly I would be causing lag for everybody else? I am also curious why you think that I believe that 1 GB of files would mean that 1 GB worth of pixels would be held in active memory. In fact, you are the only person here who made any assertion that such a thing might be true.

"Of course, after the files "load", and you've got a gigabyte worth of pixels in active memory to contend with, your frame rate is of course going to drop."

This is obviously false, since most of the scene would be culled and the remainder displayed at a lower resolution.


In any case, we seem to be working off of different metrics. You are considering only the strain placed on the observers video card, while I am also considering the amount of texture data that is being requested from the already overtaxed asset servers. It sounds to me like perhaps that thought process is causing lag for people around you. Perhaps you shouldn't be using SL

Here's one example. Whenever you change your outfit, a fairly complex process happens. To explain it as simply as I know how, it goes like this:

1. You request the asset server to deliver you the textures for the outfit.

2. The textures are then downloaded to your local machine.

3. Your outfit is baked by your local client software, and then uploaded to the simulator, so that others can see you.

Since you're on such a slow connection, it's going to take a very long time for you to upload your baked outfit. Everyone who can see you will have to wait all that time before they can see you properly. Plus, whatever fraction of network resources are going into sending the textures back and forth are tied up that much longer. What should be a process that just takes a second or two (for you, for the network, and for other people around you) now takes minutes.

There are many other ways in which a user on dial-up lags the system. That's just one. I don't think we really need to go through them all, do we? Are you getting the idea yet?



You're confusing the issue again. For the third time now, it's NOT 1GB worth of files. It's 1GB worth of texture memory. Big difference. The actual files constitute maybe a hundred megabytes.


Again, you're confusing things.

If you're looking at that chapel, which is what we've been talking about, almost no part of it will be culled. If you're standing inside it, then objects outside of it will be culled, sure, but no part of the chapel itself will be. The prims that make up the outer walls are the same ones that make up the inner walls. An object cannot occlude itself, obviously.

Even for objects that are culled, I'm not certain that their textures are removed from the buffer. If they were, then you'd likely have to reload them every time a given object moves in and out of view.

When I said "active memory", I was referring to video memory, system RAM, virtual memory on your hard drive, plus your SL cache (which of course could be described as dedicated virtual memory). When you've got more visual data in the scene than your video card can handle, the remainder bleeds over into all those other areas, and swapping between them all is what slows your machine down.


I'm considering everything. I don't know why you think I'm not.

What I've been focusing on in this discussion is simply the fact that a gigabyte worth of textures is not a gigabyte worth of files, since you very much appeared to be insisting it was. That's it.

But if you really want to talk about over-taxing the network, how about all the extra time it takes for it to deliver things to someone who can only receive them at dialup speed? In simplest terms, whatever amount of time the system has to spend focused on delivering any particular item to any particular user is time it can't spend delivering another item to another user.


If you want to continue to have a mature discussion, great. But if you're looking to throw nasty sarcastic comments into it, kindly aim your flamethrower somewhere else. There's no place for it here.

This might not be the best place for the question, but I will try anyway.

I built a lamp that turns on and off with a script that worked great, as long as local lights were enabled under graphics preferences. It doesn't work anymore and the graphics references tab doesn't seem to have anything about enabling local lights on it anymore. Did that check box move some place else?

CTRL+P
Graphics tab
Make sure 'custom' is checked on the right top
Central, near the bottom 'Lighting Detail'
Nearby Local Lights

Thanks, that did it.