Conversation with Andrew1300

(8:39:02 AM) Attempting to start a private conversation with Andrew1300...
(8:39:03 AM) Unverified conversation with Andrew1300 started.
(8:39:34 AM) Me: i think i am having a pretty brilliant revelation here about another potential application of the axiomatic/algebraic/graph approach of software modeling
(8:40:09 AM) Andrew: Ok...
(8:40:10 AM) Andrew: Go on
(8:40:15 AM) Me: how about streaming medium-rich ray-traced scenes to clients?
(8:40:21 AM) Me: losslessly
(8:40:34 AM) Me: arbitrary resolution (maybe, sorta)
(8:41:20 AM) Andrew: Hmm... like... sending the objects?
(8:41:31 AM) Andrew: Or something like vector for ray-tracing?
(8:42:05 AM) Me: the goal of this methodology of software modeling is to break software down into whatever constituent parts, no matter how high level or low level, to best suit your needs, which generally means simplifying for one of a few specific resources by which you may be constrained: memory, computation, bandwidth
(8:43:32 AM) Me: one of the neater things is that you can design software which you will deploy to separate machines or separate processes or threads/processors whatever, and communication between the different threads can be optimized by the computational graph for whatever you're needs are going to be -- in the situation i'm proposing, you'd be optimizing mostly for bandwidth, but secondly for CPU
(8:44:19 AM) Me: to be honest though, the special move is that you don't really need to design your software for this at all if you don't want to -- i just assume that if you conceive of a software task that is conceived of for an express purpose, it will be better at that than if you hadn't
(8:44:43 AM) Me: imagine you had a scene with a bunch of objects
(8:45:02 AM) Me: every object can be boiled down into primitives and rendering those can be boiled down to simple functions
(8:45:26 AM) Me: things like light sources and occlusion can be calculated on the server-side and sent to the client(s) in real time
(8:46:20 AM) Andrew: Yeah, true
(8:48:15 AM) Me: now of course this graph system would be the one responsible for making these decisions, but as a means of example i imagine one potential scenario where the most optimized way to send scenes to the client is to pack up your models (compounds of primitives, including light sources and other localized visual effects) and send those over a multiplexed channel, delta functions for those models' transformation matrices, and finally, the real special move which prevents the client from having to actually DO ANY raytracing: send some well-compressable multichannel framebuffer that encodes which primitives/lights/effects are relevant at each fragment on screen
(8:49:14 AM) Me: hell, a moving model could simply be a model that takes t into account as a variable
(8:49:48 AM) Me: and you could even compress model data by using a notion of "specializing" a model to inherit a new model from it -- perhaps a moving model from a model without a movement (no t variable)
(8:52:46 AM) Me: this is sort of akin of that code snippet i found one time that takes a series opengl command and produces a PDF output containing flattened vector graphics
(8:54:23 AM) Me: for that matter, you could easily apply these techniques to more conventional means of rendering 3D graphics (ie. faster than raytracing) but the thought that you could get ray-tracing quality at a fraction of the cost by what amounts to a highly specialized computational distribution of the workload... that seems like a really cool idea to me that has broad implications
(8:55:42 AM) Me: hell if you could get the overhead down low enough, you could actually play video games this way. the video game could be raytraced, and reside entirely on a server. you could monetize it by making it like an MMORPG, and forcing players to play in groups (like FFXI)
(9:04:35 AM) Andrew: Interesting idea, not sure of it's actual feasibility real world though. I don't see why it wouldn't be possible though
(9:32:53 AM) Me: ok like
(9:32:57 AM) Me: imagine you had a sea of grass blades
(9:33:25 AM) Me: hmm... that's a bad example... that's exactly the kind of thing that has more visual elements than pixels and would be easier to just send the pixels
(9:34:29 AM) Me: well, i suppose that's a practical problem with trying to apply this to raytracing: why would you raytrace instead of using more conventional techniques if you aren't even going to have beautifully detailed scenes with many more visual elements on screen than pixels?
(9:35:05 AM) Me: i mean to be fair, the system could send SOME parts of a scene in PIXEL form if that was deemed more efficient
(9:36:06 AM) Me: but yeah i think that's the nail in the coffin. you'd want really beautiful scenery, and that wouldn't work over this medium too well.