kf6kjg / anaximander2 Goto Github PK

Specifically if there's a missing table reported by a MySql.Data.MySqlClient.MySqlException then a nicer error than an exception crash would be good.

Currently all faces are rendered solid, alpha is ignored. Would be neat to be able to make transparency work, even if edge cases like prims crossing each other are not handled "correctly".

Current renderer just draws OBBs, not actual prims.

Instead it'd be neat to actually render into a 3D orthographic projection.

Both #7 and #6 would likely be fixed by doing this as well.

When there are ground-prim interactions, the prims are currently always rendered above the terrain. They should intersect each other.

This is a TODO item in Program.cs near line 240:

// TODO: hook up the filters.  Takes config entries.

When prims overlap the region boundary into void space they are cut off: no prims render beyond the edge of the region the prim is in.

Possible solution:
Void regions adjacent to existing regions should be considered as regions. This has to account for situations such as a void surrounded on all 4 sides and 4 corners with regions that have prims overlapping into the space. Solving this is doable, but might be complex. If accomplished, it would be a one-up - as long as it doesn't violate #4's disambiguation between water-only regions and void space.

Currently the prims are rendered using only the prim color: since most prims are colored white this means the maps are mostly just white.

This implies the following subtasks:

• The ability to fetch the texture asset from the asset server.
• The ability to determine a reasonable average color for the texture. - I think this one's got code in Halcyon that I can purloin.
• The ability to cache the texture's UUID along with the resulting color information for fast subsequent lookups. This cache should have a disk-based backup to survive restarts.
• The correct color-merge algorithm when rendering. SL merges the prim's color with the prim's texture, and Anax should do the same.

The code uses a spin loop and needs to be changed to a wait handle. There's a TODO in the code for this.

Currently the code draws all prims that fall under land height at prim origin + 256 meters. This means the maximum height that drawn prims can be found at is a function of the terrain height.

This behavior comes from SL but is weird, like so many things LL.

Currently the offline regions are rendered with a fixed solid color. This could be changed to simply do a post-process on the rendered tile: set the hue to a specific color, put in an overlay image, something like that.

Exception: System.Net.Sockets.SocketException (0x80004005): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.1.137:32700
at System.Net.Sockets.Socket.Connect(IPAddress[] addresses, Int32 port)
at System.Net.Sockets.Socket.Connect(String host, Int32 port)
at InWorldz.Whip.Client.RemoteServer.Connect()
at InWorldz.Whip.Client.RemoteServer.Start()
at AssetReader.AssetServerWHIP.Initialize(IConfig settings) in C:\projects\anaximander2\Source\AssetReader\AssetServerWHIP.cs:line 65
at AssetReader.AssetReader..ctor(IConfigSource configSource) in C:\projects\anaximander2\Source\AssetReader\AssetReader.cs:line 84
at Anaximander.Application.Main(String[] args)

This is due to a filter that limits which prims will be drawn based upon their height above the terrain in OBBRenderer.cs near line 320:

if (
	// skip prim in non-finite position
	Single.IsNaN(pos.X) || Single.IsNaN(pos.Y) ||
	Single.IsInfinity(pos.X) || Single.IsInfinity(pos.Y) ||

	// skip prim Z at or above 256m above the terrain at that position, but only if actually above terrain.
	// BUG: will still cause discrepencies when the terrain changes height drastically between regions and the prim is in the high "iffy" area.
	(pos.X >= 0f && pos.X < 256f && pos.Y >= 0f && pos.Y < 256f && pos.Z >= (MathUtilities.GetBlendedHeight(heightMap, pos.X, pos.Y) + 256f)))
	return null;

As noted this will only happen if the prim is near the terrain+256m altitude limit, overlapping into an adjacent region, and the terrain height in the adjacent region has an altitude change enough to invalidate the prim in that region's space.

To solve this the region would have to know the adjacent region's terrain.

See https://rollbar.com/kf6kjg/Anaximander-2/items/47/

Preconditions:

• OS is Windows
• [Assets]:CachePath is set to an existing folder
• [Startup]:MaxParallism is -1 on a multiprocessor or hyperthreaded machine, or is greater than 2.

Error:
The process cannot access the file 'C:\websites\newgrid\anaximander2\AssetCache\b8\d3\96\5a\ad\78\bf\43\69\9b\bf\f8\ec\a6\c9\75.pbasset' because it is being used by another process.

Possible solution: set some flag that results in FILE_SHARE_READ being used. http://stackoverflow.com/questions/3527205/multiple-threads-reading-from-the-same-file may be of service.

Requirements:

• Headless operation: no dependencies on X11, no requirements to be on Windows, etc.
• Render to image.
• Non-commercial license.
• Operates on Linux.

Would be nice to have:

• Able to render without a GPU.
• Able to render with GPU acceleration.
• Operate on Windows.
• Operate on MacOS.

Non requirements:

• Doesn't have to render in realtime - though speed is a nice feature.

Currently the renderer assumes that all islands use the same base terrain textures. This is very much the same problem as #1.

This implies the following subtasks:

• The ability to fetch the texture asset from the asset server.
• The ability to determine a reasonable average color for the texture. - I think this one's got code in Halcyon that I can purloin.
• The ability to cache the texture's UUID along with the resulting color information for fast subsequent lookups. This cache should have a disk-based backup to survive restarts.

Just as #21 deals with terrain, this deals with prim faces.

In theory this should be as simple as computing the angle between the normal and the "sun direction" vector in 3D. Then 180deg is full bright and 90 deg or less is full dim. Tuning the endstops and the curve is the exercise.

The code currently doesn't check to see if super tiles need to be removed. It should, even though the likelihood of this being an issue is minor on a growing grid.

If the RDB host cannot be found for a region, because there is no entry for it in the RegionRdbMapping table or no entry for that in the RDBHosts table, it should assume the same host as the core database. Anaximander does assume that, as far as I can tell. However, when it switches to use the core db host, it also changes the other connection string parameters to the core host connection.

Problem configuration:

MasterDatabaseConnectionString = "Data Source=db.host.com;Database=grid;User ID=..."
RDBConnectionStringPartial = "Database=grid_rdb;User ID=..."

Note that the Database= entries above have two different names.

The setup on Islandz is such that there is no RDB mapping but the database itself is named islandz_rdb. Anaximander correctly contacts (falls back to) the core database host, but when it does so it ignores the RDB-specific connection string in the Anaximander.ini RDBConnectionStringPartial setting.

This is going to be a bit of work. Several of the NuGet packages in use have died in favor of .Net built-ins. Conversions will be needed.

NuGet Packages

• Nancy: everything it provided should be now part of .NET.
• Trove.Nini: There's nothing in .NET. We should consider moving to a better config format, say YAML or TOML. I'm not a fan of XML configs.
• LibreMetaverse: Exists in legacy .NETStandard. Should be usable.
• NUnit: Exists in legacy .NETStandard. Should be usable.
• RestSharp: Exists in legacy .NETStandard. Should be usable.
• zlib.net: Needs replacement. It is suggested to convert to SharpZipLib.
• Chattel: Needs an upgrade itself.

After much testing this is caused by the Prim.cs SELECT statement's subselect to get the root prim rotation. The source of that trouble seems to be the lack of an index on the prims.LinkNumber field.

The problem here is that the megasculpts doing the offshoring are larger than the region and their OBB covers the region entirely, resulting in a big single color blob.

When regions are adjacent and prims overlap the region boundary they are cut off: no prims render beyond the edge of the region the prim is in.

Possible solution:
All 8 adjacent region's prims should be brought in to the list of prims for the current region and then filtered for intersection with the AABB of the region. Remaining prims are then drawn. This will solve the region-region primcrossing render oddity.

Old idea was just to make the void a slightly different color.

Current preferred idea is to be able to specify overlay images to be baked into the images for sim water while leaving color the same. Ocean (void) tile imagery would be left plain.

Comes from this comment in Program.cs:

/* Issues to watch for:
* TODO: Tile image read during write - The web server could attempt to read a file while the file is being written.
*  - Possible solution: write to a random filename then try { mv rndname to finalname with overwrite } catch { try again later for a max of N times }
*    This should provide as much atomicity as possible, and allow anything that's blocking access to be bypassed via time delay. Needs to just fail under exceptions that indicate always-fail conditions.
*/

I had to disable the selfshadow code early on as it was badly messing up the coloration on land that was shallowly tilted towards or away from the light source.

3D rendering would likely take care of this, but there might be ways to get it back in operation without the odd effects.

Code is commented out near line 275 of OBBRenderer.cs

Region tiles are being removed when a region is simply offline and offline regions are supposed to be drawn. Kinda looks like I missed the read-side hookup.