Won't implement Render Void region water without gaps between void and actual sim

This feature request will not be implemented

Bob Wellman

New member
I have already posted all about this to the firestorm Jira the details of which you can read using this link https://jira.firestormviewer.org/browse/FIRE-29076. If you cant read that link let me know and I will post the details in here too.

Basically there are circumstances where the scene renders voids with a gap between the water in the void and the water in an adjacent region. I have it in my own PMGrid where I use different water heights in adjacent regions. I noticed that XMIR grid does a similar thing and that all viewers seem to have the same issue with this. Whilst it would be hard to solve this in SL I think it should be possible in opensim, without server side code changes. as explained in the Jira.

I think Gavin is probably the best person to bring this to as he is both an opensim grid owner and interested in Dayturn being useful to opensim specifically.

Let me know what you think please.
It is basically a renderer issue that must be solved fundamentally by LL who knows the renderer (actually even they don't properly).

You said in the JIRA it works on your grid. Exactly how? (as in detailed, practical example including code if there is some.)

Also you have to keep in mind that on any grid but a personal one, a region owner is free to set the water height at any level, and it seems to me from the proposal it will impose a constraint on this grid-wide which is not acceptable?
Thanks for your prompt reply.

I cannot see where I said in the Jira something works in my grid unless you are talking about the ability to add stuff to grid info.

If so then yes anyone can add any new parameter they like to the robust.ini or opensim.ini and it gets ignored by robust and opensim if its not required but can be retrieved by an HTTP call from a web browser or by the viewer.

Please go to a web browser and enter this:-http://pmgrid.org:8002/get_grid_info
and it will return ths:-
<location>Essex England</location>

Try the same on XMIR grid substituting you grid uri for mine and compare.

You will observe I have added a location parameter to my .ini file to describe where PMGrid is located in RL. This has no effect on opensim as it ignores parameters its not looking for. Similarly I could add a sealevel parameter and you can access that the same way.

BTW you can also retrieve this in LSL inside the grid. See http://opensimulator.org/wiki/OsGetGridCustom.

Now I agree it would be better for large grids if there was also a SimInfo section in opensim.ini and an HTTP call that retrieved that too. Then each sim could specify what sealevel to use when seen from that sim. But that would require cooperation of the opensim devs which is hard come by. They would immediately say there is nothing that needs this data, and unless we have my suggested change they are right.

So I think its a 2 step process. First step the ability to specify sea level for the grid. Second step to get opensim changes to allow sims to override that.

PMGrid, XMIR grid, and many small grids would benefit immediately from step 1, but OSGRID would need step 2 as well to be workable. So OSGRID probably wouldn't set sealevel until step 2 was available..

Now that covers how the viewer can know whats wanted.

However if changing how the viewer decides what height to render water in voids is really buried inside the renderer itself, and the renderer is too difficult to change, then its no use knowing whats wanted anyway cos it cant be done.

I had assumed (possibly wrongly) that the simulator says render water in the mountain sim at 30 m, render the adjacent costal sim water at 20 m and render the voids at 30m (cos it has no better idea than set it same as this sim). Then I assumed the rendered was called to do as asked for the scene.

Perhaps if you tracked where the region water height values are used in the veiwer code it may become apparent that my guess was right or it may confirm its really inside the renderer and my assumption was totally wrong.

At least then we could definitively say its possible or impossible to do this without renderer knowledge.
I just reread your post Gavin and, in case I am not clea,r no change to how the water in the sim is rendered is propsed,. That stays as now. Its just how voids water is rendered we are talking about. Void water hieghts filp about as we change sim and thats what we aim to fix.
The problem is that they way it is set up, the renderer can only draw system water in the same plane as the horizon, so you cannot lower the horizon as you would have to do to make it look correct, and still keep the system water at the desired level in the current region without a major render change.

The issue is similar to the one you get when you set negative terrain depth which is technically supported by the simulator, but not by the renderer.
I think maybe you have identified the solution in your own post. Water in voids is rendered at same level as Horizon and horizon is set to equal the water in the sim you are in rather than being independent/constant. So horizon raises and lowers as you move around with no ill effects except the void water.

Can I suggest a proof of concept test.

I have sent you a photo in world of a view in your own grid that demos the problem. Can I suggest that you take a look at that view yourself. Next can I suggest (in a test version of your viewer) you set horizon always to 20m (which is your sea-level for your coastal regions). Then using that test viewer you take the same photo. One of 2 things will come from that photo. You can either demonstrate definitivly that moving the horizon is as bad as you assume or that it make the scene look better as I suspect.
It most likely will make many scenes look better, the issue at hand is that horizon cannot be set at a fixed global level for a grid of any size as it will look very strange for higher elevation regions that don't have system water in view.
Also remember that the normal mechanism is to paint a watery horizon for a view outside own region +1 . If you fixed the horizon globally at 20 m for a grid, it would look most ackward for higher elevation regions.
I do realize that we need different sea level for different sims.

That was not the point of my post. The point was to do a simple "Proof Of Concept" test to see if it is possible to change the horizon without delving into the renderer code as you said at first.

If this proved to be possible then I agree we are left with the question of how do we know what level to use in which sim to make it look good everywhere. I have some ideas on that.

However the logical way to proceed is one step at a time. See what the POC test show in this one instance. If the POC shows it cant be done there is no point in chasing the goal. If the POC shows it can be done then we still have to resolve the other issues around it, buts its worth making the effort to do that. The extra issues would need opensim changes but lets not get ahead of ourselves. Will moving the horizon look better in this one POC test?

Of course the other approach is to close our eyes and imagine what might happen. That has never been my approach to an issue and never will be. If you do not wish to do the POC test is it possible for me to do it myself?.
The horizon is implemented as a skydome with radius 15000 meter so I presume you would have to manipulate that, but then again pulling it up or down 20 meters may not have any particular effect at all.

As much as I would love to have it fixed, as it is annoying in some scenes, I don't think I will want to spend much time on researching and testing it given a large number of other priorities with the viewer, including the upcoming eep release which maybe even will have a solution to it.

Please be free to pour over the code yourself.
Right. I know it was not the reply you wanted.

My assessment is that despite the relatively simple logical solution, given the fact it is a long standing issue that is unresolved in the LL rendering code, the possibility of implementing it in the current codebase is complex.
As the upcoming eep release will implement per-parcel environmental settings where local water height has been discussed as part of the solution, it might be better to re-evaluate the issue when we see the full eep implementation.
Thank you Gavin. I think I am now not hearing "no" but rather I am hearing "not now maybe later". That is fine and I do realize you must decide on your priorities. You have only so much time and other things come further up that list than this for you. That is a fair call. If I can help in any way, testing maybe, please don't hesitate to ask.

Members online

No members online now.