Inline and abridged... and rather long anyhow. I *really* like some of the ideas that are getting tossed around.
On Tue, Aug 9, 2011 at 2:05 AM, BGB <[email protected]> wrote: > On 8/8/2011 6:55 PM, Casey Ransberger wrote: > > I almost missed this thread. I'm also hunting that grail. VR for consumers > that isn't lame. CC'd FONC because I think this is actually relevant to that > conversation. > > My feeling is, and I may be wrong, that the problems with Second Life are > twofold: > > > [sorry in advance, I mostly ended up running off in an unrelated direction, > but maybe it could still be interesting]. > You're fine, I do it all the time:) IMO, probably better (than centralized servers) is to have independent > world-servers which run alongside a traditional web-server (such as Apache > or similar). > This appears more or less to be the way OpenQwaq works. I'm pretty sure that I haven't fully comprehended everything the server does and how that relates to the more familiar (to me) client, though. I note that the models and such seem to live on the server, and then get sent (synced?) to the client. > one can jump to a server using its URL, pull down its local content via > HTTP, and connect to a server which manages the shared VR world, ... > Ah, you're talking about running in a web browser? Yeah, that will probably happen, but the web browser strikes me as a rather poor choice of life support system for a 3D multimedia collaboration and learning environment at least as of today... OTOH I guess it solves the problem of not being able to deploy (e.g.) GPL'd code on platforms like iOS. I should say that I'm a huge fan of things like Clamato and Lively Kernel, but I'm not sure the WebGL thing is ready for prime time, and I'm not sure how something like e.g. Croquet will translate at this point in time. I also don't have a Croquet implemented in Javascript lying around anywhere, and it's not exactly a small amount of work to implement the basis. I don't even understand how all of the parts work or interact yet... > a partial issue though becomes how much client-specific content to allow, > for example, if clients use their own avatars (which are bounced along using > the webserver to distribute them to anyone who sees them), and a persons' > avatar is derived from copyrighted material, there is always a risk that > some jerkface lawyers may try to sue the person running the server, or the > author of the VR software, with copyright infringement (unless of course one > uses the usual sets of legal disclaimers and "terms of use" agreements and > similar). > Heh, yes. Fortunately there are places one can go to purchase assets which can then be used under commercially compatible licenses... to be honest, though, the avatar I've been testing with is *cough* Tron. Found it on the web and couldn't really resist. Got to take him out of there before I can deploy anything, I think, but I Am Not A Lawyer, so I can't say that I actually know, and like most folks, I'm going to play it safe... what I do know is that this is slightly embarrassing :O Working on an original protagonist/avatar for my "game" but she's not quite done yet. It's all dialed in but the clothes aren't right yet. Having to learn to use this pile of expensive 3D animation software as I go... I really wish I could just draw everything using a pencil and then use a lightbox to transfer the keyframes to cell and paint, but I don't know how to make hand drawn animation work in 3D. This is actually why I was curious about the availability of the sources to SketchPad, because that constraints in 3D idea seems to underly the automated inbetweening that goes on nowadays and you could do stuff in 3D using a light pen with SketchPad, which seems better than what I have now in a lot of ways. > allowing user-created worlds on a shared server (sort of like a Wiki) poses > similar problems. > the temptation for people to be lazy and use copyrighted images/music/... > in their worlds is fairly large, and nearly any new technology is a major > bait for opportunistic lawsuit-crazy lawyers... > So it *seems* like the way most businesses deal with this is by taking UGC down without quarter whenever someone complains. I'll probably end up having to do something like this. It's still painful because one then needs to employ people to actually handle that every day. I don't know, maybe there's some way to use community policing to accomplish this. In my view, though, if it happens, it isn't the worst problem in the world to have. It means someone noticed that your product/service or what have you exists! And if it was fatal, I don't think YouTube would still be on the internet. In fact all of that "bad press" probably helped YouTube get traction. yep, and there is a question of what exact purposes these 3D worlds serve vs > more traditional systems, such as good old web-pages. > I think being able to point at things and see by the eyes and the angle of the head what people are looking at (shared attention) are probably pretty powerful in general. We have a very disjoint communication experience... I have to keep track of phone calls, video, the (grumble) stream of mostly useless information which comes my way from the social networking site that my friends have increasingly replaced other, less noisy communication mechanisms with. And what kind of error message is "Message is too long." when I didn't even write enough to constitute a short story? It's hard to actually make a whole point with the stuff people are using now if you like to supply supporting arguments. The best way to have a conversation with someone is in person, but with my friend in Florida, this gets expensive quickly, etc... and I won't be able to visit my friend in Argentina very much at all, much less introduce him to friends I've made in Seattle in person real soon, I'd have to save to do that. I think when the 3D displays get cheap, natural user interfaces become common, and computer animation starts to exit the "uncanny valley" this stuff will start to look like a pretty good idea. The consumers I've talked to pretty much tugged my coat and said adult the equivalent of "Momma, want" but I haven't convinced any business folks that trying to sell it is a good idea yet, and I have a feeling that's going to be pretty hard. > games is a major application area for 3D, but the more open-ended world > that is non-game systems is a much bigger problems, and the relative merits > of 3D are much less obvious. > Yeah and a new medium is like... it's like pitching that an investor, who really wants to invest in a nice painting, should instead invest in a new kind of canvas. Ends up being a hard sell. I looked at the list of universals and settled on "play" as the best bet, so I focused on ways I might build a game of some sort in there. If I can get the tech out there, people will pretty rapidly figure out that it isn't really a game, but merely contains one. And then people will likely figure out what it's for on their own, bit by bit. This is my thinking, anyway, and I may well be wrong. a partial issue at the time though is potentially the reasonably high costs > of producing decent-quality 3D content (models, maps, ...) in contrast to > most other content. > When I realized that I was going to need the paraphernalia of 3D gaming, there went my savings... and a lot of my time, since I was the only person I knew who'd done any animation. > the industry-standard tools are typically expensive, have a steep learning > curve, and still leave content production a rather long and tedious process > (it is, in contrast, much faster and easier to produce spiffy-looking 2D > graphics artwork, or for that matter to edit documents in a WYSIWYG editor). > I'd even go so far as to say that a lot of this stuff is still rather counterintuitive, but I know mileage probably varies. And yes, my kingdom for a way to do 3D animation that resembles what I did with my pencil, my fountain pens, the cells, the paint, etc. It ends up being more like a combination of Python, puppeteering and sculpture nowadays, and I have confidence that I can rock the Python, even though I've never used it, but the other two are things I don't have previous experience with. The automatic (I can only assume constraints based under the hood, but it usually doesn't come with source code except for Blender, and the UI on that one seems strongly resistant to the ways that I want to interact with it out the gate) inbetweening often does weird, grotesque, physically impossible contortions, causing me to have to go back and do my own inbetweens manually on a regular basis. I've been using Blender mostly to convert file formats, and commercial tools to do the animation work, because I simply didn't have time to learn to use Blender effectively. The commercial stuff seems a little less... alien, but it's also not terribly easy to learn to use. For me. Also, a hand drawn character looks less... creepy than the current state of the art puppet, even if the puppet is more realistic now. Uncanny valley. In a long shot I can make the spitting image of a real life human being surrounded by beautiful, lush, procedural/fractal terrain, but in the close up, it just makes me want to cry a little and call my mom. And, the other issue I have is spending hours to see what the final render will look like for a single frame is isn't economical, so I have to work with images that don't look anything like the final product most of the time. This is a pretty big problem for me, and the only solutions I know about are a) buy or rent a compute cluster, and b) wait a long time. I can't currently afford to do either, so I have to work with preview renders in the wrong resolution, the shading minimized, and basically clothes that look completely tattered and don't even move right until I'm ready to cross my fingers and pray that the final render won't come out completely wrong for some reason I couldn't perceive in the early version: this is a lot like that awful "get coffee and maybe lunch while my code fails to compile" thing. also, there is also the general problem of a lack of non-suck free DCC > tools. > yes, I have my own 3D DCC tools, but sadly, they are not exactly non-suck > either... > Really? That's just so cool. Right now I feel like the caveman in 2001 who figures out he can use the one thing to smash the other thing and gets really excited about ways this might help him eat after he has an encounter with the monolith. 3D is a tough nut to crack. > another problem at the present time is the general lack of freely-available > 3D artwork, meaning much content production has to start from the ground-up, > from basic cubes and cylinders (again, this may have something to do with > the present sad state of DCC tools). > +1 and we know what the problem is too, it's still too expensive for most people to learn, do and give away. > Minecraft has been running with an honor system for awhile now, and > people just don't seem to mess with each other as much there. > > yes, but a lot may also be that there is no centralized Minecraft world, > but instead most servers are run on an individual basis and only admit a > limited number of players. > That's an interesting point. I'm going to run in a different direction on this one, though. There's a service called freeshell which is about free UNIX shells. They had some trouble with abuse once, and so they voted to change the rules slightly, so that in order to get email you had to make a $1 donation (this got rid of almost all of the spam) and to get a more fully featured shell account, you had to pay... I think my lifetime ARPA membership cost me like $30 if I remember? This got rid of more "sophisticated" forms of abuse. To set up certain kinds of services requires greater contributions. This seems to have worked for freeshell, and may also work for immersive technologies as well. Note that e.g. Second Life offers free accounts... > thus, the target for destructive behaviors or vandalism is spread very thin > (people are far less prone to try to vandalize peoples' personally-run > servers). > This is a good point, but it may also be that people are playing Minecraft with more people they know in real life, which is also a little bit interesting, no? but, in some ways, I think Minecraft represents something "fundamental", but > I don't really know what it is. in many ways, it has created something thus > far reasonably unique in the world of gaming. > Well, so it does two things really well, it recognizes that people of all ages can stack up blocks shaped like things in the real world and then knock them over for fun. It also includes cellular automata that users can use to figure out how to make complex dynamic behaviors without having to necessarily be taught (though programming with Redstone is not the first thing in the game people figure out... you have to figure out how to survive and dig down to the bottom of the world in order to obtain it, and programming is relatively hard.) > I also find voxels interesting, but there is an uncertainty where the > future of 3D lies (moving on from the present system of polygonal geometry). > voxels are one option, but not the only option. > I like fractals. But it ends up being a mix in all likelihood. Voxels are great for doing clouds at a distance, etc. But up close clouds made out of little cubes aren't very convincing. Minecraft overcomes this by making low resolution textures and huge voxels a kind of fashion statement. > in my case, I build partly on a different system: CSG. > Had to google that and it showed up below the fold. You mean this, is that correct? http://en.wikipedia.org/wiki/Constructive_solid_geometry > although CSG is not exactly new either, people are far from using CSG to > its full ability (like voxels, objects built from CSG are "solid", and so it > is possible to cut/modify/... CSG-based objects). > > also, the initial up-front cost of CSG (memory, rendering overhead, ...) is > much lower than with voxels (and, CSG can usually be fairly easily converted > into polygonal geometry for rendering/...). so, when a piece of CSG geometry > is altered, its polygonal geometry can be fairly easily rebuilt (unlike with > a mesh model, where there is nothing "in" the model beyond its external > geometry). > > a downside of CSG vs voxels is that voxels have all of their complexity > up-front, so however the scene is changed the voxels remain approximately > the same cost. however, supporting alteration of CSG-based geometry steadily > increases the amount of internal geometry (creating new primitives and > cutting holes with negative primitives, ...). so, a Minecraft-like game > world couldn't be so easily created with CSG. > > I have before had ideas for trying to combine CSG and voxels, but this is > itself a complex problem area. > > even more compelling would be if both could be combined with FEM and > similar, allowing for structures which could be built initially from CSG > primitives, broken apart or modified at a fine level of detail (as with > voxels), and subject to mechanical forces (bending, flexing, fracturing > under strain, shearing, ...). > It's so much fun being an eternal beginner! Okay so now you're talking about this, right? http://en.wikipedia.org/wiki/Finite_element_method > it could be very cool, but poses a few problems: > It sounds fantastic? > how to implement it?... > You got me. > how to make it able to be used at *any* real scale on current HW > (voxels+FEM is not exactly a lightweight combination). > What if the "simulation overhead" could be distributed to every machine currently participating? One might even apply an idea like ocular occlusion in order to avoid simulating things that no one is present to perceive at the cost of some realism (if a tree falls in the forest, and there's no one there to compute it, it can't affect the butterfly that flaps its wings and makes it rain in Singapore, to mix some metaphors badly.) > then again, there may be a partial way around it: the system is built > top-down from CSG. > > at the high-level, it is just CSG primitives, and this is how the world is > initially built; > CSG geometry may be animated/... through more traditional means (treated as > polygonal geometry and subjected to weighted vertex transformations, ...); > as-needed, the geometry may be "decomposed" into analogous voxel geometry > (if done well, the transformation can be handled a single primitive at a > time and in a reasonably transparent manner). > > and, if most of the world remains as CSG, then the overall cost can be kept > lower, and in regions where there is severe alteration, it transforms into > voxels. > So my fractal planet takes some voodoo that I don't yet understand in order to be converted to a particular level of detail (the mesh and map) that I can use with conventional 3D applications, and I've also been thinking that multiple representations for different kinds of graphics and physics related computations might be an interesting line of inquiry, but sadly I'm presently missing math that I need to envision what that looks like. It's nice to see someone else who understands this stuff better than I do thinking along these lines, especially since I currently have no plan for what I'm going to do when I find out that a real time physics engine is what I actually need, and I understand that these are not small or easy to build either based on the bit of web searching that I was able to do. an example of this would be, say, one creates a big sphere of "sand" in the > sky, and it proceeds to fall due to gravity (at this point, the engine sees > a plain sphere). upon contact with the ground, high-forces (exceeding > certain defined constants) cause the sphere to break apart into voxels, > which are then subjected to internal physics (moving forwards at their prior > speeds), and then stopping once there is nowhere for them to go. > potentially, the engine leaves this as-is, or may begin trying to > "recompress" these regions of voxels back into CSG geometry where possible > (say, a big cube of voxels all of the same size is replaced with a "cube" > primitive mapped to the given material type). > Yep, that sounds really cool, and my gut says reducing to primitives wherever possible might help make performance of higher resolution volumetric simulations more feasible? Although I suppose if all you have is voxels, then you only have a single primitive, and number of primitives in play is supposed to affect render time? *Sigh* need more math. > and, from the point of view of the user, they just say a big ball of sand > fall from the sky and splat on the ground, leaving a sand-pile... (itself > subject to being readily deformed, say the user shoots at it and puffs of > sand fly off and pile up elsewhere, and ones' weapons deform the sand pile > and leave their bullets embedded in the sand, ...). > That's what you want yeah. Stuff that behaves like real stuff:) > an analogy would be the current partial integration between bitmap and > vector graphics, but what if this were 3D?... > > > granted, all this is mostly speculation, and not really something I can > pursue at present, and it may still be some years before this sort of thing > is really practical on consumer-grade hardware... (by "practical" I mean: > can be applied in real-time to large-scale game-worlds, in contrast to the > reasonably small scales typically seen in most voxel+FEM+physics examples > thus far). > Imagine something on the scale of an MMORPG and think about ways you can distribute the math across as many machines as possible. Is what I've been thinking for doing simulation stuff, anyway. I'm not sure this is a real advantage but I bet you could at least get yourself a lot of computing power. > also, the comparably lower costs of plain CSG and rigid-body physics make > them currently a much more attractive target, as these work much better on > current HW. > And with most real time physics engines, objects have a habit of randomly exploding due to the lack of accuracy in the simulation, which invariably means having to manually install dampening, which can also cause objects to implode, right? I read a paper about that somewhere when I first looked into doing physics. There was just no way I was paying for a commercial engine, etc... and then OpenQwaq ended up being released, which looked more like what I wanted out of the box than the "game engines." > OTOH, Minecraft works as well as it does because its voxels are very low > density and there are almost no large-scale physics (it is not possible, for > example, to build a large structure, and have it break loose and fall over, > ...). > Right, and this is both an artistic constraint that produces interesting art, and probably a real limitation to the kinds of art that one can create in Minecraft. > voxels could also have potentially cool uses if combined with 3D printers: > imagine if, for example, one could build some large electronic device in a > Minecraft like system, print it out, and have a real and working piece of > hardware... > Uh... heh. I wanted to do something like this with my hardware project, but I looked at what it takes to build an ALU with Redstone and thought "yeah this thing really needs turtles." Which is what got me thinking about Logo. > it could very well be possible given the existence of conductive and > semi-conductive polymers, ... > I think yeah just the FPGAs will be good enough for now. or such... > > I'll spend some time reading these. Thank you. > note: > http://en.wikipedia.org/wiki/Voxel > http://en.wikipedia.org/wiki/Constructive_solid_geometry > http://en.wikipedia.org/wiki/Finite_element_method > http://en.wikipedia.org/wiki/Computational_fluid_dynamics > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
