Effects, we're a bit behind :/

that's what it looks like on my geforce too. look at how the water seems to cover land in the distance. That's the problem.

Yes, that's a lot of work.

The way a BSP map works, if I recall correctly, (it's been a while since I made a Quake map) is it takes the entire map, from ALL possible angles, and "solidifies" the geometry. IE, the computer, during compilation of a BSP tree, knows that the player will never see an outer portion of a wall, so it simply doesn't render those polygons in the final BSP tree. Or, if you want to get fancy, you can put certain types of shapes into the map (clipper brushes, I think?) that would force the BSP map to "cut" the polygons from the view, to further optimize the map.

Then the lighting is applied (again, totally pre-computed in most parts; if it's dyanmic lighting, it will lag horribly, and that's even WITH a known geometry to light). From there, sometimes you have a "vis" program (at least with quake-engine games) that further optimizes the building tree for all possible angles.

So what you have is a big blob of a file telling the computer exactly where everything is at load time.

SL cannot do that without severely curtailing the ability to change objects on a whim.

SL renders all the prims in a scene because the client has absolutely NO idea where the camera angle will be pointing at next. None. You have total freedom in your camera angles; the only thing the client can reasonbly assume won't be rendered is the underside of terrain (which poses a problem for "edge" sims... take a look at the edge of grignano for an example). Everything else has to be loaded in "just in case". It would shatter more of the suspension of belief if you mvoed your camera suddenly and the neighbor's house wasn't there behind your wall!

Besides... by the time the theoretical optimizing system rendered a scene "efficiently", it would have drastically changed again. All it takes is one prim moved/deleted/created to cause a recompile of all possible scenes in the view of that prim.

LF

How much data are we talkin' about there, Lordfly? Maybe that stuff could be calculated and streamed on a per-parcel basis? Not that we are in the position to do anything about it other than talk smack.

I have only done a little coding in 3d engines, and that was to play with physics rather than making pretty pictures (cuz i'm not an artist), so I don't really know how all that BSP stuff works. But just from a logical standpoint, it seems to me that the rendering should be done from the camera outwards. Let the client determine what gets rezzed first.

And yeah, while the engine could use some improvements, it's really all about art. You guys have seen what WoW looks like, and that engine is fairly mediocre when it comes to benchmark numbers. Coders don't make art, they make tools. Artists make art. People who aren't able to make quality content won't suddenly be able to because of an engine upgrade. That stuff takes skills which really very few people have.

I have to wonder about how much we can emulate high-end games in this environment. At any time, someone can drop a script on an object. As far as this discussion is concerned, you could be radically changing the rules on how an object is rendered.

Hopefully, we are like months behind and the Lindens are already all over this.

And lastly, seems like a couple weeks ago I read an article on Wired.com about some breakthrough that could eliminate electronic bottlnecks. That means we can read data off the net as fast as we read it off of our disks. And I don't think I need to tell you tech-heads what -that- means. Keep your fingers crossed.

A long time ago I made some suggestions in this forum to streamline the order-of-render. I actually had a chance to briefly talk with Cory about one or two of my ideas, and I have, over the year I've been on SL, noticed an improvement on order-of-download.

But imagine being able to streamline the engine and game even more by:
- Upping priority on the queue for objects very close to you
- Adding a logical "box" object that you could put in your land to donate "inside" - any avatar outside it will render objects inside last. Any avatar inside it will not render objects outside last.
- Create an object that on a scheduled basis scans through the sim and searches for sources of lag - high resolution BMPs, open listens, particles, etc - that list could be e-mailed to landowners on a weekly / monthly basis (perhaps how often they want)
(a player could create this)
- Hire a Linden Lab employee whose sole duty is to come up with ways for players to identify lag problems and build cleaner builds - to host classes, update web contact, and work with mentors to educate newbies.
- Ultimately, make the asset and content servers distributed so that the load can be distributed and we can avoid exponential growth on databases.
- At the very least, have seperate content servers for different large regions of the grid - as well as a centralized server for objects that are duplicated over several region content servers.

Please accept some lack of knowledge coming from a very amateur 3D programmer - I just had a semester of it, ages ago, where we put up together a ray-tracer, running on Windows 3.0 and with just 16 colours on a 640x480 screen and which rendered, oh, perhaps one frame in a minute on a good day So obviously I'm fully ignorant of the state-of-the-art technology in current 3D engines...

I was completely flabbergasted about the number of polygons rendered for complex prim hair - 340,000?? And we still get 20+ avatars in clubs with all their prim hair, and something like 5-10 fps? Why are we complaining? I'd say, SL's engine must be the best engine in the history of 3D programming if it really is able to render TENS OF MILLIONS of polygons on low-end graphic cards, and still deliver a few frames per second!

Yes, I've seen 10,000-polygon scenes rendered at 100 fps. Suddenly I'm not impressed any more. Why, an empty sim with just my AV in it will have twenty times that number of polygons, and my lowly Mac notebook is able to give me 30 fps or more on an empty sim. Cool

Well, considering these numbers, I'm actually at a loss to suggest what could be done to "improve" SL's rendering engine... except for following Hiro's suggestions of teaching people to create low-lag (but still professionally-looking) buildings and textures. But that has nothing to do with the 3D engine. I think I'm almost fearing SL 1.7 or so, with Havok 2 and new bump maps, and suddenly people having 340,000-polygon hair with each polygon having its own bump map... and a ray-tracer on top of it, to make the hair shine when it moves with the wind! I'm not sure if I my budget allows me to buy a Cray supercomputer in 2005, just to render a billion polygons with ray-tracing and give me 50 fps...

I think that LL is taking the correct approach, which is slowly improving the engine, allowing the technology & Internet bandwidth to become better and cheaper in time, and better able to handle a more photo-realistic VR. If a billion-polygon-50-fps graphic card is available in 2010 for just US$100, I prefer to wait until then to get photorealism in SL. I don't need it in 2005

Not exactly; the polygon count depends of your quality settings; and also the size of the object in your scene (I assume a lower-resolution polygon count prim is generated on the fly, depending of the distance from the viewer). for example, a spere of 2 pixel high can be rendered as a "cube".
Crazy hair twirls are another issue...

If we could simply get "mesh" prims; lot of these complex object could be less complex.

I also agree that LL is doing great by improving the engine as the time pass as you said. But; its just that, from my technical view point... the current model is not easily compatible with the tech needed for realistic lighting, reflections, environmental mapping, etc. A shift in the way of doing this will have to be done.

Personally, I would be ready to sacrifice some "dynamic" aspects of the world; in order to have lightmaps, cubemaps and all the other eye candy a "pre-computed" world has to offer.

Or maybe I just played too much Half Life 2 and Doom3 before hopping in SL ;-D

you can fake some of that good enough to not be worth sacrificing anything dynamic. it's the dynamic stuff that makes sl unique anyway. don't take away people's ability to be creative just for some flashy visuals.

anyway LL is working on a new renderer so maybe people should check into what they've said about that instead of saying here's what they should do.

Absolutely ! I am craving to see what the new renderer will look like.

Philip Linden promised that early in 2005 we would be able to see some of the snapshots they have done with the "new renderer"...

The problem with reflections and refractive ripples is that in those games, they're pulling some VERY dirty tricks to do it, tricks that simply would NOT work in SL.

What they do is they basically make what's called a "Cube map" which is a weird sort of screenshot of the area that gets distorted... SL's content is extremely dynamic and any reflections of that sort would either have to double resolution and then kick the shit out your video card for pixel shading, rendering an otherwise uber system to the level of a 2D only video card choking on software only rendering of the entire scene...

I would like the reflections my self, but unfortunately it's not quite as easy as many games make it look... The fact that those games have very static content that's always the same all the time means they can pull dirty, sneaky, little tricks to make it LOOK like it's actually doing something complex but it's actually not.

Sorry...

As for meshes... We're talking about allowing people to make objects with an absolutely massive polycount... And then to upload them to the client... As it is, SL only has to pass the parameters of the prims which is a hell of a lot less content than sending the entire shape of the prim itself... Simply put, if they allowed meshes, we're talking about far more lag, especially on the assets server. Then everyone'll be complaining even more than they already do about lag....

As for bumpmapping... Making custom bumpmaps is quite possible and I'd love it...

As for light mapping... It's already in SL if you pull some sneaky, dirty tricks... Funny you should mention that. As soon as the servers come back up, I'm going to be uploading some lightmaps for my head to make my eyes glow in the dark (I have a luskwood prim head, though the textures are mine). And my eyes will be glowy with light maps from here on out

Some of you may remember the Tron'esque discs game and how the discs actually glowed in the dark with a light map... The Tron like discs game also had an in-house gun in the that looked like a convoluted partical-accelleration-bazooka-thing called a ROFL (Rifle, get it? hah... hah... it is to laugh...) that had the same light mapping effect.

What you would be sacraficing is about 95% of the content... Cube maps could be done if you uploaded your own cube maps to use on the prim, which would be a good compromise. Just put up a tutorial on cube mapping and if there's anything that isn't included because it wasn't there when the necessary screen shots were taken, OH WELL! I'm sure people can live without having everything reflected...

What you would be sacraficing to make the water that is a part of the sim itself do cube mapping however would be pretty much ANYTHING you can make... It wouldn't be sacraficing "some" of the content, it'd be sacraficing almost ALL of it.

As I said, lightmaps can be done in SL already, provided you know how... And yes I mean light mapping, not just changing the material to light and thus making the entire prim light, but rather an actual light map... Or rather a simulated light map, but the effect is identical.

No... because 95% of the content is "static"... and could be kind-of precomputed. I have a strong technical idea on how it can be done without sacrificing most things.

But heh... i'll stop arguing and wait to see what Linden Labs 3D programmers will do in the next release.
... then I will complain! (Joking... cool engine guys!!! heck, I was complaining about some details of HL2 engine... so... )


And yeah, about lightmaps; I made some experiences with that... yeah; cool effects are possible. The objects really "stand out" of the sandbox... too quake-style flashy and looking alien in that flat shaded world... but I didnt saw much of these while roaming the world.
Know any good places to check out for that? examples?

Lucca is basically correct, although speaking in 2005 and moving forewards terms, many of the desired effects can, and probably will be done not by fixed function methods and additional bitmaps but dynamically by pixel shaders.

(the exception being cube (reflectivity) mapping which would still need to be assigned screenshots... though given the overall abilities of even the current newview.exe client it wouldn't be so hard to imagine an automatic 'cube map creator' function which would be able to upon creation of a reflective object, optionally take over the user's rendering and quickly snap the 6 basic screens required (with dynamics such as avatars and particles off) and assemble them into the required texture)

as to meshes, no i do not believe that will happen anytime soon in SL.. and its not even necessarily the video card thats the hangup there... yer average cut twisted torus has at least as many polygons as a LOD optimized mesh (say 2-3000) the problem becomes more one of network bandwidth.. one of the major reasons for 'prims' is that you can save a complex shape as a relatively small set of 'deformation's of the base object, and pass those to the client... with a mesh, there is no way to do that and you would essentially have to be passing back an forth rather large arrays of poly coordinates for each mesh object... something that could easily get out of hand, or look weird if meshes slowly accumulated detail dynamically as they downloaded

except that SL servers are not clients, they have no rendering/display context in which to draw/create these maps, nor do they have the video hardware (or spare processor cycles in busy sims) required to do so in all likliehood


-aka what that means is that the maps would have to be created on the client, and then uploaded to the server and attached to the object, assumably in a manner i described above.. that works okay except it means each object would reflect what was 'fixed' in world at the time of its own creation and there would be literally no means to update it as things around it changed.

I have often wished we could get water in SL the same as the very good water in Project Entropia another MMORPG virtual on line world... there the water is swimmable and the AV has default animation ( just like walking) and on enter water it starts, same in Neocron also another virtual world on line.... Water in SL isnt really active and is pretty poor, and doesnt interact.....

Another thing is reflection,. a much simpler on li9ne creative fagem called Moove has variable total mirror effect which can be applied to walls or objects and reflects whatever happens in front of it in game

love for these things to happen in SL one day

That's partly my point...

As for the content being static... By static, I mean it cannot... under any circumstances move... AT ALL... It's not static if the object owner or land owner can come along and just push a button and OH it's gone... then why do we have this reflective cube map (which requires screenshots) reflecting anobject that doesn't exist? What happens if someone drops a new object? Removes it? Moves it? Turns it upside down or inside out?

Just because the stuff doesn't move much doesn't mean it's static... Static vs dynamic is less about how often it moves or changes and more about how it's being handled...

If you want to see the kinds of problems we'd get in SL if we had dynamically created cube maps (which we'd need) try downloading the Tenebrae Engine for Quake and turn the reflections on high-res and try running it at four times your normal SL resolution, which you'd have to do because SL's renderer generates everything in realtime in software unlike Quake which just needs to read the file for the meshes. And we're talking ancient low-polycount Quake here and the dynamically created cube maps on the Tenebrae Quake Engine cause any video card and cpu combo to choke.

You could, I suppose, have it automatically create ONE cube map automatically when an object comes into range, but that could cause some serious issues with ram. And if there are too many prims in an area, we'd be talking about a sizable delay just to get into an area.

It'd be much simpler and not overload everyone's CPUs, to simply allow people to create their own cube maps to use. When talking about cube mapping on SL, we'd HAVE to make some sacrafices. We can have the cake but not the frosting. Or we can have the frosting but not the cake... Or we'll just have to settle with low-quality chocolate icing instead of rich fudge icing. That's my point.

Heres a few things that could basically be done 'now' to improve the overall SL rendering quality, without requiring whole code rewrites of the display engine.. some are obvious, some are a little arcane, some would be huge, others subtle.. but all of them could easily make it in with just an hour or two work each (assumably).

1) 'volumetric' particle generation. Basically just add in one additional (optional) paramater to the particle system, InnerRadius. It would be assumed to be equal to the current radius (renamed to outerRadius or what have you) if not present, but if set specifically it would basically define a volume, not just a surface, within which to do the current particle system. many MANY people 'fake' this effect now, simply by having repeated particle calls on timers, and a random number passed for the radius each time... condensing that functionality into the call itself would not only enable effects not physically possible now, but would reduce lag caused by people varying the paramaters manually to attempt to fake it

2) 'random/cyclical color' particle generation. Similarly to above But rather than begin and end colors as we have now (which should still work) you would be able to set a start HSL value (hue, saturation, lightness) for he particle system, and a 'morph' vector to be applied to it each spawn interval aka the ability to start with something the equivalent of <0,1,0> green (in h/s/l terms approximately <0.5/1/1> and apply say a <0.125,0,0> 'morph' as the second paramater, this would start the particles green, and successive particles would be spawned through the primary/secondary colors... having all this done on the client would be much faster, and less server intensive, than current timed llFrand() calls to the particle system over an over for color changes

3) 'truly local' lighting... essentially local lighting as it is now, is unusbale because people simply jus set far far FAR too much light.. this prevents its artistic use within the game as well as causing huge lag for anyone who has it enabled... all i suggest is that if you are in parcel X, all objects *NOT* in parcel x be considered as 'non casting' to the lighting engine, aka like they were not set light at all... this would just let people actually USE the current local lighting, which actually does look very good, when its not being abused badly

4) custom bump maps.. this one is a no brainer, basically jus have a picker for a second texture to be used as bump on the primary one's color. Its already there (though with fixed textures) so all that would be needed is a little interface workup and yer basically done

5) 'over bright' color spacing. basically rather than clipping all colors (as floats) at 1.0, record the actual value and just display it in the final pass as if it was 1.0. This would let people do some interesting color trickery with things like particles where between the start/stop color spaces, you could start with 2.0/1.0/1.0 start, and 0.0/0.0/0.0 stop color, and you would get particles that would spawn white <1,1,1>, bleed red at the mid point <1,0.5,0.5>, and finally terminate at black <0,0,0> (essentially its another idea to get more interesting color morphing effects than are currently possible)

6) 'prim' avatars... this is more of a design choice but enable people to select a 'sphere' avatar in place of the humanoid one, upon which they could build a more complex/custom avatar framework... its sort of already there with custom squished up animations, but heck thats jus wasting alot of client polygons with an av that will never be seen. (just have them all be size 1,1,1 fixed so people can't 'be invisible' with them any more than they could now)

theres a bunch of others im sure, these are just all relatively simple things that each seperatly would not be hard at all to implment, and would let us do somethin either we can't do now, or are rather busily lagging up the game to do without realizing it, in many people's cases

Yeah, until the next "update" of the object by the owner. "Recompute reflections" button or something likethat. That can be seen be a 10L$ operation, since it would be a "new texture" Computing that on the client is not a good idea...
And... in HL2 the material reflections work that way... a precomputed cubemap. (maybe precomputed when the level is loaded, not sure)

The water reflection is something else, with the scene rendered upside down and used as a projected texture distorted by the water shader. That is only a render workload and a shader task... rendering all things "over the water"; no need precompute or to put anything static.

[well... correct me if I am wrong with these statements; but thats what I deduced after playing a lot with all effects on; and toying with the level editor ]



Yeah. I would be fine with that; if thats a optional feature you can enabled on a prim group. Most houses and clubs dont move around and floor doesnt disappear each time the owner says "abracadabra!". (well, it can... but for most of the places, we dont want/need that.)

I dont want reflective water or floors reflecting the window light... jut a way to setup easily a prim, or a prim group to have a more believable lighting. Dont care if that prim group is to be locked in place by that operation.

Until then, manual lightmaps are the way to go...

Yah actually thats a very specific pixel shader that they use there (somethin SL does not have the ability to do at the moment) that basically takes advantage of the fact that (generally) water never reflects something behind you (aka it can only reflect, client side, things already on your screen)

Ok, so basically, you want for any idiot to be able to take several thousnad prims and just attatch them to the land there permenantly with no way of removing them, to be uploaded to everyone's clients as a permenant addition to the land? I don't think so! The only thing "static" in SL is the land, and even that is dynamic!

It's not a simple matter of making something not dynamic... If it can be undone, it's dynamic. I seriously doubt someone's going to want to buy the land which has objects that have been made permenant, it's just that many fewer prims they can build with.

In Halflife 2, it works because the content is static. You cannot simply go into a level and say "Oh, I don't like this wall here, I think I'm going to unlink it and delete it."

HalfLife uses hardware computations for figuring out where things go. Half of SL's rendering is software, it's not so easy to do it fast... Again, the best way to do it is to screw the automatic updating of the cube map and simply allow people to make their own cube maps...

Would not allowing you to specify your own cube map not be worlds better than NO cube maps? With the CURRENT way the engine handles things, a dynamic cube map will only serve to slow things down to a point that we have to wait 10 years for the computers to be able to run it at a playable speed... If the new renderer can handle it then sure, but lets wait and see... Maybe they found a way to make new renderer automatically BSP everything and turn all the prims into a solid mesh for the purpose of rendering. That would definitely make it viable... but don't get your hopes up, SL is already pushing the limits with CPU time...

The main problem lies in the fact that SL uses the CPU a lot more than Half-Life2 or anything else... Those use the video card more than anything. SL uses the CPU more than anything. It's less a matter of "is it technologically possible" and more of a matter of "can we squeeze it onto the already overworked CPU without the system bottlenecking"

As for the lighting you want... Try turning on Local Lighting (oh wait, that's evenmore of a CPU hog)... with Local Lighting turned on, anything with its material set to Light will produce a dynamic light effect, BeDazzle often OVERUSES this trick. The larger the surface with the light material is, the more light it produces... a 10x10 face will produce so much light as to massively washout most things nearby... Try it out some time...

Lightmaps however are basically a texture that lights up only certain pixels in the dark on the texture, and not other pixels. Like say a glowing circuit board that only looks glowing in the dark, it looks normal in the day time.