X4.01-d | is this a bad idea?
Mmm ... OK. Maybe it isn't.At least ... "the thing" is telling me that it isn't. The technical term would be 'Segulo' - which is how I named it and since I don't think there's a technical term existent in this world yet, that's what it's ... actually called. Apart from whatever actual term God would be going by.
I suppose I have to write about it at some other point; I may have mentioned it before - but nowhere in 'the contemporary text' of this site. It's a testimony thing. Essentially an imaginary box that's supposed to pass through a kind of forcefield/threshold. And despite its boolean nature it's quite nuanced. I'm still puzzled over how to estimate its accuracy - though I think the two primary factors are personal clarity and God willing. So, while I technically rely on its accuracy - I've also learned to ignore it at times; Which comes down to how it behaves or how I feel about it.
Anyway. So ... after having done some of the rewriting/renaming and touch-ups here and there; I've also come around to doing some of the intro-screen stuff; While technically still stuck on that problem.
Much of the rewriting/renaming came down to consolidate the previously mentioned and thus far established 'solution', with the problem now being the nitty gritty of ... basically applying that to the next problem; Which comes down to ... I guess we could say 'control flow and usability'.
Though at the heart of it is, I suppose, an ideal - the problem is to figure out what that looks like. I've gone back and forth on a few attempts thus far - though it's more like multiple back and forths of varying degrees accross the spectrum of the issue, that may or may not have led to some degree of spaghettification of the code; So ... part of what I'm working on right now is to clean things up. Again.
And the thing is that there ... are, or seem to be, a lot of "movable parts". Though there aren't, in and of itself, a lot of ways to go about it - there's, due to the amount of parts involved, a large variability of where to put what and how to organize things. And so, I come to a first glorious insight for what to focus on - which is the fact that the ideal depends on the multiple processes and tasks that the system has to accommodate for. Though, I guess so far it hasn't ever really helped all that much to "focus on the process" - due to how many things any one of those processes that I kept being puzzled over would need.
But I sure have to keep that in mind.
In fact - that's kind of why I'm writing this.
Instead of this being simply an update ... I actually meant to work out a solution for one of the problems I'm facing. Which is, I suppose, just to wire you into what I'm currently looking at. So, we're roughly on the same page I guess.
So, the problem right now is two-fold. On the one hand side I'm trying to make room, or space, for implementing the drawing/rendering routines into the structure; And on the other I'm trying to figure out how to best make that structure "internally consistent", we might say.
To better explain what I mean or what I'm looking at, it might be best to take a Galaxy as an example. And I just realize how much potential screen-presence a Galaxy might have. It would seem to be the most ... problematic celestial structure I have to deal with. Well, depending - of course - on how mu... well.
So, the big thing is that from afar a Galaxy is but a point. That is - depending on the resolution - there's an amount of pixels a Galaxy of a given size and distance would occupy on the screen. Below a certain amount, a simple sprite will do. Above a certain size I might want to consider going a bit further - as to perhaps allow some distinction between the Galaxies. At least, perhaps, between those that are just 'empty' and those that actually have stuff in them. Then, a bit closer still and the individual structure of the Galaxy becomes something to be mindful of. At any rate - that is the mid-point between sprite and up-close-and-inside representation.
Now are Galaxies however also only one of a few things that I want to have there. It's also one of those things that are perhaps only things at a distance, while 'up-close-and-inside' the thing disperses into something that wouldn't necessarily stand out. But to properly work with how to structure those elements, I first need something to work with. But that's a different story.
Parts of it at least.
Right now I'm more concerned of the virtual framework. And apart from wiring the rendering routines into it, there's also a concern to make it virtually functional. And the way I feel about that, it comes down to trying to not overlook the Forest for the Trees.
The big problems are I think first of all rendering problems. When those are adequately solved, so it might be, there's also a foundation for the virtual aspects. I mean, that's ... something that ... seemed to make sense while I tried to outline the drawing components.
I mean - to ... get stright to the core of the problem I meant to discuss here:
There is or would be a certain logic to the depth of space. At first the issue is mathematical and that establishes the basics of what I'm working with. So, with a draw-distance of 1000, I say that a Galaxy with a radius of 500 is the upper limit of what works when being inside one. Sort of. For galaxies larger than that, some extra math-magic has to be done.
Also, based on that, an "inner void" can be calculated. Within the proper limits that would be a radius of 1. So, the inner void is where things are 'too close' to be drawn. On "the other side" is the "target area", or how to call it, which is a radius around the target spot for various proximity enhancements, such as ... moving from sprites to higher detail models. Using that are as a base - a new 'maximum radius' can be produced. So, if we say the radius is 50, the new upper limit would be 50000; Which is well beyond what I need.
And that might be the first thing for me to take-away. Though it's always been ... itching on my mind - I find it difficult to hold on to these ideas or insights ... in the moment. Like so I might be staring at my code for hours - unable to move on because all the ideas are more on the vague side. That ... and I'm usually working on other things that make it difficult to see the connection.
The next thing is also - well, now more of a "duh" moment. I mean, the general layout of these structures entails we might say a box that has an "entry level" ('full size') and a "target level"; But so far I struggled to make proper sense of the in-between. That because technically it doesn't need to be there - and ... oh, OK. I ... yea. Issues that at first don't pop up.
Anyway - so, here VR and Rendering co-incide in that the various layers of detail co-incide with the proximity enhancements required. But uh ... .
OK, so - to summarize, for me the solution right now is this: As an environmental compound, these structures need to be set up by type; Rather than magnitude. The basic detapoint required is the 'target radius' - which alongside some possibly globally defined buffer space factor also produces the loading thresshold. This 'target sphere' is thereby also associated with drawing mechanisms more or less unique to itself. The problem here is to make sense between different types of structures that exist on the same magnitude. But ... more on that ... later?
This drawing stage is distinct from the environment's "full size" representation - while on setup additional layers need to be added in case additional layers of detail are needed. Each of those also requires a radius that then matters for loading and drawing - and technically may stretch the top-limit even further but that's beside the point.
One reason why I didn't like it right away is that this 'distance scaling' messes up what I call the 'Vectorspace'. And here the issue is mostly ... I guess ... a form of stubbornness. Or what we germans call "standing on the hose" or "having a long conduit" - to say, processing speed is impaired, if present at all. I mean, I'd try to make it easy on me and maintain that these different layers don't require me to translate position coordinates of moving objects between them. And to keep things within limits is like a superstition born from an earlier approach to the problem. Like so, while the only concern was on the ground near stuff, it seemed reasonable to have different units for different layers as that's how the grid should work. In deep space things are a bit more flexible - at least a grid isn't really all that useful anymore - at least not on par with a tile-based surface - and so I somehow got something mixed up it seems. For, the matter is that the distance scaling can all be computed into the modelview matrix. The units don't need to change. So, the vectorspace is consistent up unto the limits of the floating point numbers used. And that's dawning upon me now that I've somehow imposed it upon me to deal with whatever side-effect the conclusive solution requires. Does this make sense?
Uhm, yea. Being forced into situations can change our perceptions. That's also why people emphasize experience over theory. Or otherwise argue that making mistakes is important. If you can learn from them.
Anyway ... I guess this is ... enough for now.
I mean ... also often enough one can also overthink things; Spending too much time writing about a thing, or drawing blueprints, as opposed to just doing it. I mean, it depends - I suppose - on the situation; And one's mental capacity.
Peace!
:) ... I recently got the payback(?) from my electricity bills - uh. For having used less electricity than I paid for, I got around 200 bucks back. It was tempting to spend it on the MGEX Freedom Strike, but I opted for something else; Though the shipping fees exceed the costs of the kit itself. It ... seems really unreasonable ..., but still cheaper than getting it from e-bay. I mean, it doesn't seem easy/cheap to get hands on ecopla kits outside of Japan. Which also begs the question if it's still ... 'economic' ... but that's more ... a problem for another day.
