jakj

Freakachu, that makes a scary amount of sense. I didn't think of that because it's so opposite of the way I work: I have trouble getting things done at all, because every time I learn something new, I go and rewrite everything, and then I keep reviewing everything I've written to see what can be made better, so after days of effort I end up with 1-3 extremely-tight classes instead of 8-9 functional ones. :D

Well, it wasn't that he didn't understand GL lighting, because he does use it in a limited way in the code already. And it wasn't that it's less work to do it this way, because it's a whole lot more work to do lightmaps and light-value propagation in the chunk handler and all this other business. The only thing that I can possibly think of is that somehow he felt he had to do it this way, that since the world was made up of blocks, and the liquids were blocks, and even the sun and moon were blocks, that the light should be blocks too. It's not like occlusion was a concern, either: That's the code that Jeb's just getting around to now, years later, getting light to wrap around stuff and pass through stuff horizontally (though reflectivity is clearly well beyond even his current motivation). The same code that would handle the lighting in the first place (ambient is a simple multiplication; diffuse is a dot product followed by a multiplication) would also handle the very basic computation of vertical occlusion like the chunk handler does now. -And- it could still stick to GL 1.1 like it does now, with no shaders at all, for maximum portability.

Yeah, that confirms it: Not actually changing the system from the current, and it's still light values stored in blocks. He's just altering the ways it's calculated, stored, propagated, or whatever, and that'll barely have an effect on Forge. It's really frickin' annoying, because right now, it's impossible to set a block to be opaque (as in it casts a shadow beneath it and kills grass below it) with a custom renderer without Minecraft drowning the thing in darkness. Even if you disable every single part of the block's Vanilla rendering code, it still uses the block's opacity value to draw a shadow on it.

You can modify the lightmap, yes, but only once per render frame. The mod would have to somehow detect there is a redstone torch nearby, and modify the lightmap, but that would make regular torches, lamps, and fire also emit the red light. The lightmap is generated conditionally per dimension (so each Mystcraft age could have a different lightmap, just as overworld/nether/end each have their own lightmaps.) Sunlight, for example, is done by the lightmap. Even though Minecraft actually has 256 values for sunlight reaching a block (marked as opacity), every block is either completely transparent (subtracts 0 from the light that passes through it) or is completely opaque (subtracts 255 from the light that passes through it). (You can set different values for it, if you want, but no vanilla block does.) No matter the time of day, a block out in the open is always at sunlight value 255, but the lightmap is drawn with darker and darker shades of grey as the sun goes down, so when multiplied against the block's color, it dims. (I might be a bit off: I haven't looked at that code recently, but it may be that it subtracts 1 from the light value for each block downward the light goes, so at the floor limit of block 0, the light would have reached 0. I think it probably does that, but I'd have to look at the code to remember.)

Uh...no. Unless we're talking about vastly different things, here, no. Minecraft's lighting is done by storing lighting values as a block property and propagating them under certain circumstances, which is why you get those shadowy places that update when you walk near them. Minecraft has something called a "lightmap", which is just a very small texture in which one axis is relative to natural light (like the sun, or the nether glow) and the other axis is relative to artificial light (like torchlight). When rendering a block, Minecraft calculates a coordinate into this lightmap based on how much natural and artificial light is reaching the block, and then multiplies the block's base color by that color. (This is why torches make things slightly yellow, but only if they're not in sunlight, and why things appear reddish in the Nether.) Real GL lighting is done by actual lighting sources, specified with ambient, diffuse, and specular values. (Minecraft does not use specular lighting at all.) When rendering standard items in the hand (what you're holding in the hotbar), Minecraft turns on GL lighting, which is why, if you turn in a circle, you'll notice the item in your hand gets brighter and dimmer: It's using ambient light, plus two diffuse lights above your head, one on each side, which are not related at all to the actual block-lighting conditions. It's still multiplied by the lightmap to get dim in caves. Because most things in Minecraft never rotate, block-rendering code does not use GL lighting, but instead simulates it, and if you look at the code, you'll notice that Minecraft uses specific color multipliers based on which side of the block is being drawn. In my Imaginarium mod, I've had to re-create the Minecraft fake lighting with real ambient/diffuse lighting, which is why it doesn't always match: Basically, I'm using actual GL lighting to simulate Minecraft's fake lighting which is in turn a simulation of real GL lighting. If Minecraft were to have a real lighting engine, it would simply keep a list in memory of current light sources: One ambient light based on sunlight and location (such as a cave), one diffuse light (the sun, if visible), and an array of diffuse lights (one for each torch/fire), that would get passed into a shader. For performance, if desired, this hypothetical lighting engine could set an upper limit on active light sources, or could select them only without a radius from each other, or several other options. Even the shadows in Minecraft are not real: If you have a line of blocks (like a bridge) above other blocks, you'll notice they cast a shadow downward, but that is not done with GL lighting: It is an extra 2-dimensional quad (rectangle) drawn after the blocks, based (again) on the stored light level in the block.

Definitely sounds like another Mojang-style hack, then, instead of an actual lighting-engine rewrite. Won't be a problem, then.

I haven't noticed any significant architectural changes so far from a distance between 1.3 and 1.4 branch, so in theory it should be non-traumatic, unless their new lighting code breaks too much of Forge. Somehow I doubt it, though.

Oh, you.

Yes, the chance of a 1.3 base is near zero, unless all the major modders were to say "screw this" and stick to 1.3 out of frustration until 1.4 is mature. Considering Forge just finalized their line and is already switched to 1.4, it's more likely they'll all jump on 1.4 immediately and 1.3 will be just like 1.2.3 was, skipped over because it came too fast.

Well, the forced merge is a good thing in my opinion, even if handled poorly, because loading more than one dimension at once has been something I've desperately wanted for a long time. It actually got to the point that playing 1.2.5 was physically unpleasant to me, because I could feel that cross-dimensional loading just around the corner. Other than that, it's not really the Minecraft version that makes a lot want to update, but the Forge version. Minecraft Forge (and FML) have ripped apart the Vanilla code and sewn it back together with cyborg parts like a cross between Wolverine and the $6mil man. I'm very close to wanting to have LexManos's babies. They even hooked it so you can easily draw a custom selection outline around your block, so you're not limited to Minecraft's simple AABB model anymore.

The fuck is this? SInce mid-1.2, MCP is updated hours after Minecraft releases, and a good bit of the time, there's a working version even before the actual release, with only obfuscation alterations upon final recompilation.

Let you know what? If you want to make models, make them.

That actually made me bust out laughing. One point to you. Haha, it will, it will. As a GUI-less mod, it makes extensive use of the crafting system to compose the models to render, the tools to manipulate the rendering, and everything in-between. And that's just the default 2x2/3x3 crafting system, not any new custom one. In other news, I just finished up code to dynamically allocate buffers as they fill up (both index and vertex), so it uses only a couple megs if you don't import any new models at all, and it uses as much space as it can if you keep importing lots of models. (This means that people with a lot of VRAM can utilize it with many huge models, while people with weaker cards can just stick to small things. Or they can try big things, and enjoy the slowdown as it goes back to using system memory and transmitting the data every render frame. ) The item that clears the cache of imported models (in case you change models on the disk while Minecraft is running, and want to reload them) will also purge the buffers, so if you import a bunch of models to try out and then don't end up using them anymore that play session, and want to clear the extra buffers without closing Minecraft, you can use that item.

Vertex Buffer Objects now implemented: Insane numbers of polygons on the screen now possible. Even having to work within Minecraft's cruft (which means having to waste a lot of CPU/GPU/bus time on binding and unbinding and rebinding and enabling and disabling and bleh for every single object (item or block) during every single render frame, it's still frickin' fast. I can now officially state that (provided you have the graphics card to support it), you could have your world looking like pretty much anything. Gargoyles on your castle corners, a tapered base for your fountain (or even a spitting statue), candelabra on your ceiling, you name it. Thanks to the wonders of OpenGL and VBOs, there is a whole new layer to building and creativity in Minecraft: Up until now, you used blocks to build things. Now, you use things to build blocks! (Pretty good use of post-dental recovery time, eh?)

It's well-established that I'm male. I'm simply secure enough in my "masculinity" to choose what I like without regard to what others take from it.

Assuming he's even talking about megabits instead of megabytes, that's still absurd. 15/second? Most of the United States is lucky to get 1-3 per second maximum for their entire household. I have to assume you're pulling numbers out of your ass, because I can't imagine an ISP of enough quality to even let you download 15 Mb/s at all that would also impose a 20 GiB / month limitation. At full speed, that limit would be reached in just over three HOURS.

I'm disappointed: Making fun of my verbal diarrhea is all well and good, but this was GreenWolf's idea, and you should not have shit all over him for it in his own thread. Go derail one of mine and leave him in peace.

Since you brought it up, just to give accurate information regarding the "is the port stable", the code is "var0 = new ServerSocket(0); var10 = var0.getLocalPort();", which ends up assigning a random port.

You do like to stretch an analogy into a pretzel for your own amusement.

Bullshit: The greatest swordsman in the world fears not the second-greatest, but rather the least, because the least cannot be predicted.

Yes, I'm fortunate enough to have been brought up by smart parents just before the decline of the American school system, so I had all the tools presented to me at the right time to embrace them.

That doesn't surprise me, honestly: Most people are lazy thinkers, and instead of exploring the world for the best it has to offer, they just assume that whatever they happen to experience is the best that there is. No matter how many things in the world there may be, that have been done by smaller and fewer than him, for the people for whom vanilla Minecraft is all they've ever seen, he hung the moon.

If I can figure out a way to poll it for rough free vram, I could just allocate multiple buffers. Don't want to just do it and then fill memory, though.

It's really sad, though: What I'm doing is barely anything in terms of actual coding complexity. Most of my time is spent in delving into references and forum threads learning how all this stuff works: In the past couple of weeks, I've gone all the way through the history of OpenGL from version 1.1 to 3.1, learned vertex and fragment shaders, display lists, vertex arrays, and now vertex buffer objects, as well as the rendering pipeline and a crap-tonne else. My actual code boils down to "call OpenGL functions to draw vertices". That's it. No, really. The Internet has seen fit to provide me with algorithms at need, particularly the ones to generate weighted vertex normals, to do AABB collision (much more efficiently than Minecraft's builtin functions), and ray/facet collision with backface culling. I am proud to say, though, that I came up with my texturing algorithm all on my own: It takes any facet, rotates it to face forward, then tilts it to be perfectly vertical, and uses that to generate texture coordinates. This way, I can apply a texture to each facet individually and always keep the texture upright (so it matches the sides of vanilla blocks). I'm sure the Internet will provide me with a lovely projective-texturing algorithm for smooth surfaces when I get around to that. Oh, by the way, in terms of what I'm doing being so impressive compared to Minecraft.....well, the algorithms I'm using were published as early as 1990, and none are less than 10 years old, almost five times as old as Minecraft itself, and they're efficient enough that they're still getting linked around and used by university students to this day. (Just wanted to point that out, in case anyone here still harboured any delusions that Notch had any kind of promise as a programmer in general. I'd just like you people to think about the fact that I've learned about decades-old algorithms better than the ones in Minecraft, and Notch is older than me, is more educated than me, and (after the beginning, at least) had other people to help him at his work. Me, an absolute nobody, just doing this between Guild Wars 2 and driving a bus.) Bitter? Maybe. Still good, though.

Well, answering the last part first, there's only so much that can be squeezed in between Minecraft's already-bloated render frames that honestly are as maximally-inefficient as any human being could achieve. VBOs are recommended by most to sit around the 1-4 MiB range to make sure that they fit in any available space (and don't cause memory fragmentation) and that they are not so large that the driver decides they're too big to fit in VRAM anyway. Don't forget, amongst everything else (meaning VRAM that's needed as scratch space for normal drawing every frame), there're also texture packs, which are the biggest memory-hog around. (I have a 256x texture pack that's already over 200 megs with maximal PNG compression.) In terms of vertices required, remember that only the simplest models will be using facet normals and disjoint texture coordinates (where such differences are discernable): Complex models with smooth surfaces will have vertex normals and some sort of uniform texturing (such as projective) so that each vertex/texcoord/normal will be specified only once, and then glDrawElements (or whatever) to re-use the vertices (which hopefully will be available in the post-render cache; not sure how much I want to bother with things like vertex sorting). Assume a closed model (so all facets form a continuous surface): A huge number of vertices will be re-used. One triangle is 3, two are 4, three are 5, and so on. For a complex model, assume the first two are insignificant, and we roughly get number of triangles = number of vertices. So, your 10,000-ish polygon models are barely taking up a fifth of the 2 MiB buffer. As for the 200k+ polygon models...fuck me. No way in hell would it be of any use to allocate VBOs that large, when it's just going to go to waste most of the time. Trying to resize VBOs on the fly is fiddly, and letting the user specify the number is just asking for stupid bug-reports to come in. Probably the thing to do would be to allocate a tertiary small VBO with the Streaming hint, and then just split the model up into pieces and throw them at the buffer in bite-sized chunks. Maybe try using a mapped buffer and hope the driver connects it straight across the system bus. (But, let's be honest: I could spend weeks just working on optimization, even sorting vertices, but are we really going to sit here and pretend 200k+ polygon models are feasible in Minecraft?)