Hi Greg and Radiance folks,
Running some some simultaion with GIS data (Geografic Information System, aka 3D langscape models), there have been one or two other thoughts in my mind. As prefix:
I reckon I might be the last one using rvu routinely, - or at least as long as I haven’t ported my own program rshow from Tcl/Tk of 90ties to GTK4. NB, there’d be a couple of benefits with that.
And the project involved running renderings with larger geodesic meshes, which come with some specific problems.
There had already been some fixes by Greg to get some bits working, many thanks for that.
Anyway - here’s a list. The last three are a bit exotic, the others may deserve consideration.
-
rvu: more significant digits in view output. It uses the C library printf( “%g…” when writing view specifications, but the default number of digits is too low. It may even use %f instead. Here’s why:
For geodesic coordinates used in surveying and surface models, a coordinate system called “UTM” is now used worldwide.
UTM coordinates look like “399000.875 5284999.875 401.129” for any point on this planet. Always positive numbers, max 7 digits before the comma, and 3 following it, given in Meters.
The current numeric resolution of views output by rvu use “%g”, which has a default of only 6 digits and hence clips a position too coarsely.
For those interested, see UTM in your favourite Wikipedia language or e.g. https://www.usgs.gov/faqs/how-are-utm-coordinates-measured-usgs-topographic-maps
And yes, for those who read this and have a geodesic background: Converting to a local project-specific Mercator projection, and thus fewer digits as a side-effect, is technically feasible, but IMHO only practical and worthwhile for a few special situations. Since UTM is now (since around 10 years) the worldwide standard, and having one or two more digits in an output line has a comparatively low overhead, I argue in favour of more digits in applicable Radiance output. -
setting a cal-file variable from rpict/rvu command line
Would be neat for running script-based variations of a scene with the same cal file, but different parameters.
Any way to get this with the current SW ? -
A gensky output of sunrise and sunset for a given date. This would be helpful when running script based seasonal shading studies.
NB: the 3 variants of “dawn” could be ignore for this, IMHO. -
gendaylit doesn’t use minutes in hh:mm time definition
That makes for surprises when substituting gensky with gendaylit. - Funny that, I had advised Jean Jacques Delaunay at ISE in Radiance coding matters at the time, and it is a little puzzling gendaylit ended up that way.
Maybe support for a hh:mm time notation, instead of a floating point hour format, was added later at gensky, but not yet to gendaylit ? -
It would be useful for rvu to write out ‘t’ trace info on stdout. I hacked my version to write out the hit coordinates, and a general version needs probably to be more configurable. Yet there’s hardly other ways to get a 3D coordinate in the scene interactively, is it ? The screen text buffer of rvu doesn’t support copy&paste, and adding that is likely more work than writing to stdout.
Yes - I am aware that ximage abc.pic | rtrace … can be used for this, but then the perspective, or at least the position, is fixed. -
rvu handles SIGINT badly most the time, stalling for a period
Yes, I know by experience that getting async signals right can be a little awkward, but -hm- mostly feasible. -
rvu interactive setting of ‘me’ doesn’t seem to work
if a program started by oconv due to a “!”-input-line fails (exit code !=0), oconv should bail out with an error itself
Would be very useful to catch failing recipes in a makefile. - [There’s a side topic to this, namely how the shell handles failure of a single program in a pipeline. This bit is not related to Radiance, see “pipefail” in “man bash” for details in ‘bash’.]
Here’s the more exotic list:
-
level-of-detail (LOD) octree loading, depending on view ray distance
Consider an animated path over a terrain that stretches over a few kilometres, with different resolution available, but available memory can’t load it all at once with 0.25m resolution.
Yes, that may be a little tricky with the ambient cache.
I’m also aware that this could be solved by clever preparation of scenes, e.g. for an animation that avoids loading distant parts at a too detailed resolution. However, one probably starts to look for alternative renderers at least then. -
resident scene parts, e.g. instances that stay in mem, while others are reloaded
This speeds up the start-up time of rpict for scenes that consists of a very large part (e.g. landscape) and some smaller varying parts. Even with today’s M2-SSD storage giving > 300MB/s bandwidth, loading of a scene can take a non-trivial amount of time. The -PP option of rpict safes memory only if the whole scene is kept fixed. -
A mesh seems somewhat tricky to interface at the edges. Just wondering it’ll make sense to you if a mesh could optionally be extended at the edge towards X or Y or Z =const ?
Yes, it is more a CAD issue, but if, for various reasons, the favourite CAD package isn’t available or doesn’t handle the scene, or whatever, it would be handy. (don’t bother pointing me to your favourite CAD package that will do this.)
As said, the last three are a touch exotic, and near impossible to work with the ambient cache.
Happy redering to all, cheers and best regards
Peter