Oh, that was actually taken via BYOND? Wow, then that is rather impressive if so.
It reminds me of the Nintendo DS.
The screenshots were generated from a java program using OpenGL. The textures were taken right from a BYOND game and the environment was made to look like a BYOND game so people could see how neat BYOND games would look in 3D even if the core (the 2D maps and movement) were left alone.
People often think that 3D graphics in BYOND is asking for too much (but it isn't). These people assume that having 3D graphics wouldn't be much of an improvement (but it would be) to justify have given up hope on the feature ever being added. I made the screenshots to show that the feature would be very useful. | |
This should be put on the Feature Tracker so that I may place
| |
Regardless of the votes (side note: when were they added?) I'm pretty sure Tom has thought about a 3D display mode before.
I have a feeling that a 3D display mode was dismissed as being "too complex" because people do often complicate the issue. The point of this post was to show that it's not nearly as complex as people think it would be. It's barely more complicated than the 2D display. You can create a feature request and link to this post if you'd like. You'd get some of my 5 votes too =) | |
Forum_account wrote:
I have a feeling that a 3D display mode was dismissed as being "too complex" because people do often complicate the issue. I think you're underestimating the complexity. Even basic results, like the ones you posted above, would require massive changes to just about everything; new rendering engine, higher system specs, a new map editor, alternate game design methods, new controls, a ton of new variables, everything camera related, etc etc etc. Also, lighting isn't automatically "free" by moving into 3D. And an FPS view would depend heavily on how flexible camera controls were. | |
A 3D mode would open the door to many new features, but very few of those features are required for a 3D mode. That's why a lot of people think this feature is so unlikely - they start thinking about 3D models and all kinds of things that aren't absolutely required.
new rendering engine That's obvious. What I'm talking about is the additional work that must be done to accommodate the new rendering engine. higher system specs This isn't a problem, and if it was, it wouldn't be BYOND's problem. a new map editor This isn't necessary. alternate game design methods This is a benefit, not a problem. new controls I can macro just about any key on my keyboard, I'm not sure what new controls could possibly exist. a ton of new variables I mentioned an atom.angle var, a display setting (standing, flat, billboard, or cube), and maybe a variable to specify a different texture for an object's sides. everything camera related Aside from the 3D mode itself, this is the biggest addition. It can be handled by a single built-in proc that'd work like gluLookAt. With this, any type of camera control (fps, over-the-shoulder, top-down, isometric, etc.) can be created by the user. Edit: Also, lighting isn't automatically "free" by moving into 3D. In OpenGL it's about as easy as adding glEnable(GL_LIGHTING); to the code. It's not free, but it's much easier than adding built-in lighting to the current display. | |
Forum_account wrote:
That's obvious. What I'm talking about is the additional work that must be done to accommodate the new rendering engine.Considering how poorly BYOND performs as-is, I would say both of those should be major concerns. This isn't necessary.A new map editor wouldn't be necessary, but it would be somewhat foolish for them to leave it out. Even the current isometric map editor is somewhat lacking - you can't rotate the view. Hell, the map editor in general needs some improvements. Trying to design a 3D gameplay environment, out of flat tiles, would just be tedious, confusing, and overcomplicated. Especially if you plan on using an FPS style, or other non-top-down camera angle. This is a benefit, not a problem.I suppose, though I was thinking more for existing projects, like you posted above. People could potentially be hidden behind walls if full camera control was available, which may cause previously non-existent problems. I can macro just about any key on my keyboard, I'm not sure what new controls could possibly exist.I was thinking about built-in controls, mainly related to the camera. But also, BYOND's current mouse functionality is very limited, I doubt you could make a functional camera that worked off of mouse movements. Aside from the 3D mode itself, this is the biggest addition. It can be handled by a single built-in proc that'd work like gluLookAt. With this, any type of camera control (fps, over-the-shoulder, top-down, isometric, etc.) can be created by the user.From my limited experience, modifying 3D vectors (like those needed to control a 3D camera) is complex as hell. ...but it's much easier than adding built-in lighting to the current display.Whys that? EDIT: Plus, what about draw distance? If you pan the camera down, you would/should/could be able to see miles across the map... | |
Forum_account wrote:
higher system specs It wouldn't be a problem because: BYOND doesn't even use hardware. I've been told many times it does, but then why I lag when there's a lot transparent tiles on my screen? Even though even 1 tree in 3D has way much more transparency and it runs at 1000+ FPS (if only tree rendered). Complex scenes of Assassin's Creed and other newest games have extremely complex scenes with a lot transparency to calculate, and billions of pixels to draw each having A LOT maths do to, while BYOND lags when drawing 500x500 pixel map. And they claim it DOES USE hardware... | |
Of course it uses hardware, it doesn't magically run on thin air. The hardware option simply toggles if it uses your video card or processor. And that transparency issue is most likely from a fail in BYOND's code.
| |
Ripiz wrote:
BYOND doesn't even use hardware ... Complex scenes of Assassin's Creed and other newest games have extremely complex scenes with a lot transparency to calculate, and billions of pixels to draw each having A LOT maths do to, while BYOND lags when drawing 500x500 pixel map. It might use hardware and just not use it effectively. Commercial games make sure to fully utilize hardware. You could take a simple OpenGL demo that loads a model and renders it, plug in a model from a game, and not get nearly the framerate you'd get from the game's engine. Falacy wrote: From my limited experience, modifying 3D vectors (like those needed to control a 3D camera) is complex as hell. No matter how simple they make it, it has to be more complex than just setting client.eye. However, any complexity can easily be handled by a library. Plus, what about draw distance? If you pan the camera down, you would/should/could be able to see miles across the map This is something that may need to be changed (and would likely be changed in the future), but the current system might be sufficient for a simple 3D display mode. I'm not sure how the client keeps track of the map. ...but it's much easier than adding built-in lighting to the current display.Whys that? Because 3D lighting is handled by your graphics hardware. You don't have to write code to perform the lighting calculations, you just have to set flags to enable them. | |
bump.
/runs *cough* skyboxes too!*cough* | |
I'm often tempted to add a section to this post called "Why the 3D display would be more useful than a flash client."
I wonder how organized this code is in the BYOND client. A lot of the work for this (knowing the positions and display properties of atoms, knowing the position of the client's eye, etc.) is already being done, its just that the result is a 2D image. The switch to 3D could be very minor. Considering the isometric display mode was added (and other changes have been made to the display) I don't think this is part of BYOND's code that is too much of a mess to modify. Maybe I'll write a new blog post about this. I can't think of a good reason why we don't already have this. | |
Forum_account wrote:
I'm often tempted to add a section to this post called "Why the 3D display would be more useful than a flash client." <3 | |
Forum_account wrote:
I'm often tempted to add a section to this post called "Why the 3D display would be more useful than a flash client." It wouldn't be. Though, this could be a nice addition. I can't think of a good reason why we don't already have this. Because its far more complicated than you make it out to be, even the vastly simplified version you pitch here. Why don't you just make a library for it? That seems to be your solution for everything else. | |
Forum_account wrote:
Some existing features might be hard to translate to 3D. I'm not sure how layering would work (the built-in layer variable) because 3D gives you z-buffering for free. I'm not sure that everything you can currently do with layers could be easily done in 3D, but I'm also not sure that you'd need to or want to. Layer would still be used for overlays and HUD objects, but probably nothing else. Bumpin' this just because this is probably one of my favorite topics ever posted. | |
Kaiochao wrote:
Layer would still be used for overlays and HUD objects, but probably nothing else. I guess that's not much different than isometric or side-map modes - they handle a lot of layering for you and the layer var is used just for what you mentioned. A nice bonus here is that having 3D graphics would mean the layering is automatically correct (as opposed to isometric and side-map modes, which have situations that are difficult to resolve in 2D). Hopefully we can get the staff working on the graphics side of things again. I think the only reason this (and other graphical improvements) haven't been added is because the staff tends to avoid working on BYOND's graphical capabilities. The features being asked for are surprisingly simple, provided you're comforatble with modifying how BYOND draws things. This is just a minor change to how things are currently done - it's arguably easier to add than maptext or pixel movement. | |
Interesting thread.
October 2010: Tom talks about flash client (not even for the first time). Instagram launches on the app store. April 2012: Still no flash client. Instagram purchased by Facebook for a billion dollars. | |
Opacity is another thing that may be an issue. By that, I mean the variable, and how it affects things like sight and the view() procs. BYOND will need a new way to determine whether something is visible or blocked by an object in 3 dimensions, and maybe even by how much the object is blocked.
Transparent walls might also complicate things, as well as non-dense cubes. What do you see if the camera ends up inside a block? What if you can go underwater, where your water is a bunch of transparent, blue blocks? Does alpha blend together with different sides of the same object, or different sides of a group of connected objects? BYOND gets very slow when you have a high client.view, which has a limit of 35 (over 71^2 tiles). How large could your view distance be in a first-person mode? Of course, fog and a skybox are a must. I don't have much to say about this. The fact that BYOND's pixel movement doesn't support fractional moves also makes possible more apparent choppiness in moves, especially with how zoomed in you can get. Zooming in only makes the pixel bigger, so being able to move less than a pixel at a time would be required (ie in first-person mode, moving one pixel forward would look like a small jump, rather than a smooth movement). Otherwise, world.icon_size would need to be increased. This speed minimum (which is increased at higher framerates) has been a bother to me ever since native pixel movement came, even though there are good workarounds. But why are workarounds necessary to move at angles other than multiples of 90 degrees? Also, I think this topic might belong better in BYOND Discussion. I'm assuming most of the community blog posts were placed in the Off Topic forum. | |
Kaiochao wrote:
Opacity is another thing that may be an issue. By that, I mean the variable, and how it affects things like sight and the view() procs. BYOND will need a new way to determine whether something is visible or blocked by an object in 3 dimensions, and maybe even by how much the object is blocked. Opacity and view() don't have to change at all, a map will still be a 2D grid of turfs. They wouldn't have to take the camera angle into account (considering there could be client-side camera movement, it may not even be possible to do that). If you want to know if the player has line of sight to their target, view and opacity are already insufficient in 2D. It'd be nice to have some better built-in procs for dealing with this, but those procs are as necessary now as they would be in the future. The fact that BYOND's pixel movement doesn't support fractional moves also makes possible more apparent choppiness in moves, especially with how zoomed in you can get. Zooming in only makes the pixel bigger, so being able to move less than a pixel at a time would be required (ie in first-person mode, moving one pixel forward would look like a small jump, rather than a smooth movement). Otherwise, world.icon_size would need to be increased. world.icon_size doesn't make as much sense in 3D. What does a pixel mean when atoms are being drawn at different sizes based on their distance from the camera?. I suppose all it'd be used for is defining the default texture size and the aspect ratio of tiles. If world.icon_size was 64 and you applied a 32x32 icon as a texture, it'd be repeated. If world.icon_size was 64x32 you'd have tiles that are twice as wide as they are tall. If you could set a var on the atom to tell it to stretch the texture to fit the object, you could stretch a 32x32 texture over the whole quad even though world.icon_size is 64 - this would let you increase the resolution used for movement without requiring a change in the size of the icons you're using as textures. BYOND gets very slow when you have a high client.view, which has a limit of 35 (over 71^2 tiles). How large could your view distance be in a first-person mode? Of course, fog and a skybox are a must. I don't have much to say about this. It really depends on the environment and how much they want to optimize how the server determines what objects a client can see. Remember, when you have a first-person view you're looking in one direction. With a top-down view if you see 15 turfs in each direction, you'll see 961 total turfs. This is roughly equivalent to being able to see 31 turfs ahead in a first-person view with a 90 degree FOV. This may not be as far of a drawing distance as you'd like but it's a greater viewing distance than the top-down display offers. If you want to be able to see 31 turfs ahead with a top-down display you'd be showing the player 3969 turfs (63^2). | |
What I've been talking about in this article is the small set of changes that would need to be made to support the addition of a built-in 3D display mode. I included sample screenshots in the article to show what I mean, like this: http://files.byondhome.com/Forumaccount/3d-1.png