thanks!Quote from KnightMiner748
In Docm77's video, one of the members of the ZipCrowd turned on and off his jacket you could see it flashing in the video. So yes, turning off your hat will turn it off for everyone.
- Techy4198
- Registered Member
-
Member for 11 years and 4 days
Last active Tue, Feb, 7 2023 19:17:27
- 0 Followers
- 309 Total Posts
- 25 Thanks
-
Jan 17, 2014Techy4198 posted a message on Snapshot 14w03a Ready for Testing!Posted in: News
-
Jan 17, 2014Techy4198 posted a message on Snapshot 14w03a Ready for Testing!With the 'skin customization' button, do the options apply on just your client for everyone, or on everyone's client just for your individual player? what I mean is, if I turn hats off, does that turn MY hat off for EVERYONE, or does it just turn of everyone's hat for ME ONLY?Posted in: News
-
Dec 14, 2013Techy4198 posted a message on Saturday with Sach: Whats In a NameTechy because im a bit of a technology geek. it was actually my sister who created the 4198 part. one day she decided to sign up on the moshi monsters website, under the username Ladybird. she typed it in, it was taken. but the good old web devs at moshi monsters have incorporated a random suggestions thing, which said why not try 'ladybird4198' ? and the number has just stuck with the family ever since.Posted in: News
I know someone will mention that my actual ingame name, as stated just to the right, is conormcs, and not Techy4198. This is because, like many others, I didn't realise at the time that my username would be visible to all other players on any server I join. instead I thought it would be like most websites where it asks you for a username, password, and then a completely separate display name. because of this I use conormcs, a compressed version of my real name. I cannot wait for mojang to implement the nickname system. -
Sep 10, 2013Techy4198 posted a message on 13w36a Snapshot Ready for Testing!Also what the hell is up with sugar canes now? weird color I thinkPosted in: News
-
Aug 16, 2013Techy4198 posted a message on 1.7 Sneak Peek: Sunflowers, Falling ParticlesPosted in: News
count again.Quote from rkpkid1997Did anyone notice that it is planted at the intersection of 4 blocks? Strange...
-
Jul 2, 2013Techy4198 posted a message on The Horse Update: 1.6 Is Now Live!Posted in: News
cool signature bro /) -
Jul 1, 2013Techy4198 posted a message on The Horse Update: 1.6 Is Now Live!Posted in: News
b-team fan im guessing?Quote from chessandgo
as a pro-beta 1.7.3 terrain advocate and can say that the terrain has clearly taken a step in the right direction, using the seed 8030753765761873255 , i found, right at spawn, a mountain biome that was the most similar to b1.7.3 then all previous versions (prior b1.7.3 obviously) it had, many tunnels and arches(ARCHES ON ARCHES YEA!), many over hangs (not REALLY large ones, but pretty nice) many water falls, (5-6?) 3 lava falls, 2 relatively close to the ground, one way up, (lava stream free falling of side of cliff overhang, onto lake) a couple flouting pieces , some pumpkins and trees, 3 canyons, the bumpy/hilly terrain of the mountain biomes carries slightly over the edge of the biome, causing plains and forest to have to have some interesting hills/bumps/small mountains that transition well with the mountain biome. (sand) beaches might be making a comeback, hills and mountains in jungle, water place meant seems better, not as deep ,maybe? in certain parts (like that shallow pond/lake in the b1.7.3 glacier seed) hills seem better smoothed (when supposed to be, jagged when supposed to be) The jungle was quite large and beautiful, Jungle temple placement may changed, found temple more of in the side of a mountain than sitting on the terrain. In all honestly this is one of the best updates since minecraft 1.0.0, you doing a good job on the terrain Mojang, keep it up!
-
Jul 1, 2013Techy4198 posted a message on The Horse Update: 1.6 Is Now Live!ok. fix it. fix it now. i want custom water colorizing back.Posted in: News
-
May 25, 2013Techy4198 posted a message on Snapshot 13w21a Ready For Testing!Just wanna clear up some confusion I noticed about resource packs. they are not to add custom items or things like that, they are the audio equivalent of texture packs.Posted in: News
-
May 11, 2013Techy4198 posted a message on Snapshot 13w19a Ready for TestingYay no more blur!Posted in: News
Nice job mojang, but i do prefer the old lapis texture. no matter though, because i'm using my own custom texture pack for everything now.
for anyone wondering, it is a private texture pack. - To post a comment, please login.
0
0
It just activates cinematic camera. You can go into controls, under Miscellaneous, and bind it to something convenient. That way you can just immediately disable it while holding zoom. Don't need to toggle it afterwards. No way to disable it automatically happening while zooming though, but this is a decent workaround if you choose a convenient keybind.
0
So wait the list is meant to be blank? In that case I'd recommend adding a little message in there or something like "Blocks not discovered yet - activate any XRay profile to load" or something. Thanks for the quick responses!
0
Hmm, looks like it fixed that issue.
Another thing I noticed though... Because of the new delayed block discovery, the editor menu shows an empty list on every x-ray profile until one is actually activated. Minor annoyance, but I just thought I'd draw attention to this while I notice it.
0
Crash 1.9.4 with version 18. It hates wooden slabs it seems.
Stacktrace:
Entire crash report:
Not sure what other blocks this affects, but I have a feeling it will basically break everything.
0
When I talk about optimizations, I'm referring to things like pre-GPU backface culling, frustum culling, adjacent face culling (which would do nothing in my current 'worst-case' test environment) etc. When I mention functionality I mean, basically, not sorting polygons in the worst way possible - the focus of this thread.
The code is as optimized as I can make it in terms of general optimizations. The only other things I can probably do, would need to be something deeper which I do after all the framework is in place, otherwise it becomes a major task involving basically redoing everything from scratch for every little tweak.
Also, I feel that you're taking my frame-rate concerns a little out of context. I'm fine with the things like lack of frustum culling dropping the framerate from maybe 700 to 400 for a small testing environment, which I have mentioned I will do later on, but I must immediately deal with issues where one sorting operation per frame drops my 400 fps figure down to 5-10.
In terms of buffers, I realise that I must have been thinking of the type of buffer used processing-side. I will implement the buffer growing for only when they reach maximum capacity (how much should I grow them to? 150%? Less/more?)
Full rundown of my block implementation: (Feel free to skim over some parts, jump about for reference).
World -
ChunkHandler.
BlockStateRegistry.
BlockDataRegistry.
ChunkHandler -
ArrayList of loaded Chunks.
LongHashMap of loaded Chunk IDs (Long compiled from chunk coordinates) to Chunk objects - used to establish if a chunk is loaded at a given location, or to retrieve it. Could be compacted and optimised.
LongHashMap -
Effectively a HashMap using Longs instead of ints.
Shamelessly copied from Minecraft for now, ABSOLUTELY MUST CHANGE.
Chunk -
Block[16][16][16] all blocks in coordinate-indexed form.
Ints x,y,z (position of chunk, using 3D coordinates, see 'cubic chunks' Minecraft suggestion).
World that contains it.
Int distance from camera (chunks are also sorted by distance so that sets of transparent blocks can be rendered per-chunk rather than sorting the entire world at once).
ArrayList of all blocks that are renderable (any SOLID or CUTOUT rendering, prevents iterating through all 4096 block coordinates each time the mesh is rebuilt - actually probably leftover stuff I need to remove).
ChunkRenderer.
ArrayList of translucent blocks, sorted away from solid blocks.
ArrayList of BakedVertex for SOLID.
ArrayList of BakedVertex for CUTOUT.
ArrayList of BakedVertex for TRANSLUCENT - not actually sure what it's there for right now, looking at it.
ChunkRenderer -
Fairly complex and all over the place, will probably get its own detailed description later on.
BlockDataRegistry -
Simple ArrayList mapping of BlockData to a String for the block state (probably will end up being module:type[value1=true, value2=UP, etc...]).
BlockStateRegistry -
Simple ArrayList mapping of a String for the block state to BlockStateDefinition.
Block -
Its own BlockData object.
Pointer (Is that the right term? It's set to an existing object rather than defining new) to a BlockStateDefinition. Updated every time the BlockData is updated.
BlockData -
Fairly small wrapper around an int masked into three bytes (one byte unused, I will rectify this if it causes a major waste).
8 bits (of the int's value, unsigned, not an individual byte) for module (future expansion packs etc).
8 bits for block type.
8 bits for additional data.
BlockStateDefinition -
BlockModelVisual.
Currently unused BlockModelPhysical.
String for the block state (remember this is per definition, not stored per block object).
EnumWorldBlockLayer.
BlockModelVisual -
ArrayList of BlockElementVisual (to be compiled OR used in entity rendering).
boolean[6] of which faces can cull (solid & full).
ArrayList of BakedVertex (compiled from elements, used for chunk mesh).
Function to compile and bake the elements into vertices.
BlockModelPhysical -
ArrayList of BlockElementPhysical.
BlockElementVisual -
boolean[6] of visible faces.
byte[6] of face culling masks (ie. if the north face of this element gets culled by an adjacent block to the west - I don't really know if this is useful, I may just use 'cullable' booleans).
Vector3f most negative vertex coords.
Vector3f most positive vertex coords.
Vector3f rotation (in degrees - I could probably use short[3] at the cost of a tiny amount of visual precision).
Vector3f coords to rotate around.
BlockElementPhysical -
Vector3f most negative coords.
Vector3f most positive coords.
BakedVertex -
Floats x,y,z (wasn't sure if Vector3f has a major overhead compared to raw floats).
boolean ignore lighting (for glowing parts of blocks in situations where they aren't illuminated anyway, eg in some block/entity hybrid form - like FallingSand in Minecraft).
float baked shading value (precalculated since blocks rendered in the mesh will not have animated rotating parts).
EnumWorldBlockLayer -
Simple Enum.
NO_MODEL (to be rendered in another way, eg as an entity for moving parts).
SOLID (rendered opaque in mesh, no alpha testing or blending).
CUTOUT (rendered in mesh with alpha testing).
TRANSLUCENT (sorted and rendered outside of mesh).
Renderer uses this to quickly establish how a block needs to be rendered.
The shading was not in fact a dilemma. After a little bit of scratching my head over fairly basic trigonometry of xyz rotations, and then the obligatory half an hour of searching for the one place I forgot to ensure float divisions, all was fine. Also I could have easily used the GL_LIGHT... functions like Minecraft seems to for entities, however I wanted to ensure reliable, reproducible and predictable results across both dynamically shaded objects and baked shading. Also, from what I've seen, shaders pretty much demand the use of normals for anything useful to come out. I would like to avoid using normals for as long as possible (yes I know they're meant to be used in absolutely every situation for 3D OpenGL but they increase the buffer upload size to at least 1.25x - if I do it wrong then up to 2x - I can't really afford that when I'm already mostly wrestling with memory management in the background)
~
I would like to take the time to apologize for seeming like I'm trying to argue against some of your advice. I do appreciate the help, however some things might not be suited to my project in its current state.
0
I realise that Minecraft's renderer is generally bad in terms of performance, which is why I'm using it as a starting point for proper voxel rendering functionality rather than starting on tighter optimisation.
I am currently in the middle of restructuring the mesh renderer, block model meshing, etc. so I cannot post any understandable code right now. I will post what you've requested once it at least works.
Yes I did mean object instead of instance. I'm not sure where my mind was wandering when I wrote that.
I am not currently performing any form of culling. Again, I am first focusing on 'correct' functionality before optimisation.
To clarify, the solid mesh of the chunk is only rebuilt when a block's state is changed. The handling of transparency is still in the works but has a fairly similar first stage. Buffers are uploaded by glBufferSubData in the case that the size didn't change. If it did change then glBufferData is used. I will, when I begin optimisation, change this to use buffers with excess space, which are grown only when the usage goes above whatever the recommended percentage is (75% ?).
Thanks for that info regarding quads, I will try to implement something reasonable.
PS:
Some of the code restructuring is related to directional shading of rotated cuboids, so it's not entirely critical to this.EDIT: Shading mostly done, can focus on chunk rendering again soon
0
I am aware of gamedev.net, however I decided to ask here simply because I wish to figure out how Minecraft itself manages this so efficiently.
As I mentioned, I will of course give some code if I know what to give (I've already written quite a lot just in terms of the sky renderer, fog etc. so I can't post everything).
I am already attempting to use buffer objects, albeit through the ARB extension exposed by this version of LWJGL. However, I fear I may have accidentally used vertex array objects instead, but the actual rendering performance seems flawless so far so I doubt there are any issues there. I am also failing to see how vertex shaders and fragment shaders can be useful to a game like this, however I have already seen that it may be a solution for implementing correct smooth lighting eventually.
I am updating block distance relative to the camera before every render, only for transparent blocks (although in my current test environment everything block is transparent, to simulate the kind of situation that Minecraft would encounter with several chunks containing scattered stained glass - which by the way performs very nicely on this same system). The block data does effectively remain static in the case of solid blocks, and for transparent blocks, I do nothing but sorting.
I am sort of using compiled meshes. One for the solid layer and one for transparent. These are stored per chunk instance as public variables so that the renderer can access them without going through a getter method (I have applied this logic throughout most of the code overall). This is the first part where I can sort of see the flaws in my solution. Rather than storing block instances in an ArrayList and sorting that and then recompiling to meshes every frame, I should compile to an ArrayList of polygons*, then sort that and compile to a vertex array each frame, correct?
(* Should I store as triangles or as quads? Also what about the actual data sent to the GPU? What is preferred/recommended? Quad-to-triangle processing time, or 1.5x buffer size?)
0
For a few weeks I've been trying to create a game (which I will eventually develop into a game engine / platform, comparable to Garry's Mod), based around the concept of voxel games such as Minecraft. For the purpose of this thread, let's just assume it's another Minecraft clone. The project is based in Java, since I am much more comfortable and familiar with Java than I am with C++ or a higher level platform like Unity.
This is my first experience with both LWJGL and OpenGL, and as such I have already had to learn a lot to develop anything functional, although I have come from a background of Bukkit plugins, random Java applets, etc. I currently have fairly decent chunk management and untextured block model rendering, which can render approximately 21k static cuboids at a respectable ~600FPS on my machine.
The only trouble comes when I attempt to render transparent blocks. I very quickly discovered the need to render transparent objects in order from far to near, relative to the camera. This does indeed work as expected, however sorting needs to be repeated constantly because of player/camera movement. However, this sorting causes major performance trouble, even if I set up a way to only execute it every few seconds.
Right now, my implementation is to keep track of an ArrayList of blocks for each chunk, which is only rebuilt from the chunk's data when a block changes. Every time I choose to sort the blocks (every frame, every few seconds etc...), I first iterate through the ArrayList and update each block's distance value based on the camera's location. Then I sort by a standard Comparator. This appears to give very poor performance on this number of blocks, noticeable as major frame rate drops.
I would like to figure out how to execute this sorting as efficiently as Minecraft handles it. I assume that running the task in a seperate thread will hugely improve visual performance, however it will still result in a fairly slow update rate once I'm rendering a full world.
Could someone please point me in the right direction? Thanks.
PS: I have not included any code samples in this initial post, simply to keep it short and fairly simple. Please do not hesitate to ask for some if needed.
Also I have already decided against using order-independent translucency methods such as screen-door transparency. Finally I would like to mention that I do not wish to start using 'modern' OpenGL (shaders, etc) as a solution to problems like this.
0
Update 1.3 released at last! WOW it took a long time to do - I was not working on it much, just didn't have much time or motivation to get stuff done.
0
Thanks for the info, but I have already ensured that the latest libraries are installed. However, there does appear to be something more to this. The error occurs even when the game is started in no-sound mode (by disabling all audio devices - it confirms in the console "Switching to no sound" / "Silent mode" / whatever it was). Also, this ONLY triggers when resources are reloaded due to the connected textures option being turned on/off. It does not occur when reloading resource packs normally or via F3+S.
0
So I've tried reinstalling the game's Java runtime, then my main Java installation, nothing new. I created a completely fresh Jar file with the same MC & OF versions, CRC checked it against the one I already had, same hash so no issues there. Next thing is audio drivers.
EDIT: Can confirm that there are still issues if I force the game to start in silent mode (disabled all audio output). Not audio drivers then.
0
So I've just reinstalled basically everything for the second time in the last few days (mega virus - irrelevant). I have reinstalled the Minecraft launcher the standard way, with the .minecraft folder already containing the old world files, versions, resource packs, etc.
I've run into a bit of an issue with the game. It's kind of crashing, but in an odd way. It occasionally triggers when turning CTM on/off in Optifine. This event triggers two things (aside from actually changing the option): the button click sound, and the resource manager reloading.
Therein lies the problem - the crash appears to be a result of playing the click sound when the resources are reloading. Note: this occurs on 1.8.0, 1.8.3 and 1.8.7 versions of Optifine as far as I can tell, and did not begin until I reinstalled stuff.
The last piece of information in the console:
This particular crash (I call it a crash - the game hangs and console output ceases but the game window remains open, no actual crash report) is from 1.8.3 - I believe the OptiFine version is HD_U_B1.
It appears that some people have had similar issues in the past, and resolved the problem by deleting the assets folder. I have tried this, and it flat out did nothing. Not even a different sound that triggers the error. Ok, next solution? Delete libraries so the game practically reinstalls everything. After tidying up some 404 errors with LiteLoader download on a separate installation, I was right back to the same situation - no change.
So, here I am. Something's clearly broken beyond hope and needs to be deactivated, completely wiped and installed fresh - that's where I need your help. What is likely to be that broken 'something'? Part of Java? Audio drivers? Minecraft.jar?
I could try each and every relevant part of the system myself but I want to at least narrow down my options before potentially wasting days on this.
0
Sorry about the soundcloud page! The website I hosted the files on has shut down and now redirects to its creator's soundcloud. I will try get 1.3 out for Minecraft 1.8.x asap, but I am currently staying away for a week. I'm rather glad you necro'd this post actually
0
The full release of the 1.3 update is upon us! I'm just making final changes to a few things and then I will update the post.