Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (686)
Games in Android Showcase (198)
games submitted by our members
Games in WIP (758)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 10
 1 
 on: 2016-08-25 10:05:50 
Started by theagentd - Last post by theagentd
Hello, everyone!

As you may have seen in the "What I did today"-thread, I recently worked a bit with normal maps. I finally managed to exactly replicate the standard inputs and algorithm of 3D modeling programs, normal map baking software and all major engines out there, allowing me to use generated (baked) normal maps. My test object is a cube with smoothed normals, which uses a normal map to get back its blockiness with just some smoothed edges and corners. It all looks good...  at a distance. Zoom in and you get this:



Ouch. The 8-bit normal map simply doesn't have enough precision to exactly "unsmooth" the smoothed normal back to a flat surface, causing that blocking artifact. This is even with bilinear filtering enabled! The problem is simply that the gradient stored in the normal map to counteract the smoothness simply doesn't have good enough precision, causing aliasing (adjacent pixels get rounded to the same value), so even filtering doesn't even help if the input is already aliased.

The only real solution here is to generate a 16-bit normal map and upload it to VRAM at 16-bit precision too. That's a massive cost though. I'm currently using RGTC/BC5, which allows you to store two channels (X and Y) of the normal map compressed to half the size, with Z reconstructed as sqrt(1 - x^2 + y^2). BC5 compresses a block of 16 pixels to just 16 bytes, meaning that each normal map texel only uses 1 byte! This is a massive saving, allowing me to have more normal maps and/or higher resolution normal maps in memory. Going to 16-bit normal map precision (using the same compression trick as above) would force me to drop the compression as there is no 16-bit compression formats (at least not on OGL3 level hardware), meaning I'd need 4 times as much memory for a normal map. That instantly cuts off the first mipmap level if I want to stay at about the same memory usage as before. That's not really something I can afford. However, I read somewhere it it is possible to cram out some extra precision out of BC5, so I decided to run some experiments.

Let's first go through some theory about how BC4 and BC5 work. BC5 is just the two-channel version of the single-channel BC4, so I will be using BC4 for this example. BC4 divides the texture into 4x4 texel blocks. It then stores two 8-bit reference values in each block and 3-bit indices for each texel. BC5 is then decoded using some special logic depending on the order of the reference values. If the first value is bigger than the second one, the index describes a linear blend between the two values. If the first value is smaller, the index is partly used as a blending factor, but can also represent the constants 0.0 and 1.0. Here's some pseudo code:
1  
2  
3  
4  
5  
6  
7  
8  
index = <value between 0 and 7>
if(reference1 > reference2){
    result = (index*reference1 + (7-index)*reference2) / 7.0f;
}else{
    result = (index*reference1 + (5-index)*reference2) / 5.0f;
    if(index == 6) result = 0.0f;
    if(index == 7) result = 1.0f;
}

NOTE: This is not the exact algorithm used! The indices don't linearly map to values exactly like this! See https://msdn.microsoft.com/en-us/library/windows/desktop/bb694531%28v=vs.85%29.aspx#BC4 for exact info on the specification!

This is the basis for how we can gain more precision out of a BC4 and BC5 than 8 bits in some special cases. If we look at the exact math done here, we see that in the first case we blend together the two reference values based on a 3-bit blending factor. This gives us 8 possible colors: one of the two original colors or one of six values evenly spaced between them. So in theory, even if the reference values themselves are only stored at 8-bit precision, since we can access 6 values inbetween the two reference values we can actually get a result that has a higher than 8-bit precision in some cases, up to something inbetween 10 and 11 bits. This would be a pretty major gain for absolutely zero cost!

However, this makes one grave assumption: When a compressed texture is read, the uncompressed result is stored in the GPU's hardware texture cache. The specification of BC4 and BC5 do not require the decompressed result to be stored at float precision, meaning that the GPU is technically allowed to simply decompress to 8-bit values, throwing away any the extra precision. However, when ATI came up with BC5 it was specifically tailored for normal map compression, and they explicitly stated that they stored the decompressed values at 16-bit precision, more than enough to accurately store the decompressed 11-bit-ish result!

I decided to try check out how Nvidia had implemented using a simple trick. If decompressed values are only stored in 8-bit precision, the resulting values when sampling the BC5 compressed texture will be exactly n/255f. Hence, I disabled all texture filtering and wrote a tiny shader that calculated textureColor*255.0, and checked how far that was from a multiple of 255. If all values are exact multiples of 255 the precision would only be 8 bits, but during testing I found that certain parts of my compressed normal map had values that were completely different from multiples of 255! So, it seems Nvidia too stores the decompressed result at higher-than-8-bit precision, which is exactly what I was hoping for! However, when I tried to upload 16-bit texture data to a BC5 texture I was unable to gain any extra precision. It seems like the driver's texture compressor converts the 16-bit inputs to 8-bit inputs before compressing the texture, so it can't be relied on for this. Drats!

I plan on writing a small offline texture compressor that brute forces the best reference values and indices for each block in the texture to create an optimally compressed normal map. I have a feeling that this will improve the quality a lot, especially for gradients like the ones my test cube has.



 2 
 on: 2016-08-25 08:32:49 
Started by philjord - Last post by Hydroque

I am definitely interested in this. I will play it when time comes Cheesy
Ty

 3 
 on: 2016-08-25 06:55:47 
Started by leSpace - Last post by leSpace
Quote from: thedanisaur
Hopefully I didn't miss something but, for what it's worth, assuming solid geometry, each point must have exactly two line segments that are edges. Once you've found a single edge you can find all other edges.
Well then how would you do that ? I mean that's true, but once i have an edge, the two points are linked to other line segments ( more than one ) so how would you select the next edge among them ?



Quote from: Archive
This is a tougher problem than I originally thought.. However I dont think that the polygon that I drew could exist in your instance because you're doing a convex hull, which by definition doesnt allow these types of jagged edges, for example, this polygon would have a line going across the crests of the spikes rather than a line going down into it.
You are wrong, as you said earlier, your first idea with the planes would have worked with a convex hull. But the polygon you drew is actually possible, this is why it is a tough problem.

 4 
 on: 2016-08-25 04:51:39 
Started by BurntPizza - Last post by philfrei
I got some good debugging done for something I'm calling an "Allanspace Sound Generator". It makes a continuous, spacey collection of sine waves, with some controls for the generation rate, the envelopes, the number of tones per cluster and basic pitch spread and pan spread. There is also a weird gizmo called a "flibber" which basically intermixes tracks rather than mixing them. This gizmo was an attempt to recreate a faulty version made unintentionally that had some bizarre multi-threading issues and is very glitchy sounding.

At this point the GUI is totally placeholder, making use of a single slider tool that only shows a label and outputs a normal (0..1). AND IT HAS NOT BEEN GIVEN MUCH TESTING and will crash (turn non-functional) if you just hit "Start" without moving ALL the sliders first. If you want to give it a try, I recommend first putting all the sliders near the middle and working from there. Or wait until I figure out a reasonable GUI.

http://www.java-gaming.org/user-generated-content/members/27722/allanspace.jar

I am a bit fried and will give it the GUI more work as a side priority over the next week or two, probably. It potentially could also be run from the jar via an api, if you have a need for some spacey atmospherics.

Sounds pretty cool: get two running at the same time, and have one "flibber" and the other straight. I want to expose some controls over the "flibber" parameters, and investigate adding various forms of lfo modulation to the sines.

*

Did some research on freesound.org, for rain and wind-in-trees, for candidates effects to use in Vangard. I think I have found a couple improvements over the first wind-in-trees attempt. In the next while, I'll be expanding the api to allow ags1 to directly trigger audio events that are part of the sound-scapes. Right now she can only manipulate the volumes, not the trigger events or control the stochastic timing algos. A future api will allow the ability to control the stochastic timings as well. For the first pass (built over the last few weeks), I just wanted to get something that would work, sound decent, and could be a placeholder for a while. (The jar is 1MB and runs solo at about 1% cpu on my PC.)

*

So what I really wanted to get to today was this:

> downloaded LWJGL
> set up a project in Eclipse
> got the red block "HelloWorld" program to run (with some fussing, trying to figure out what they meant when referring to "your natives" and how to specify launch arguments which I hadn't done before)

The hello world program didn't run on my laptop (GLFW_API_UNAVAILABLE error. but it IS running on my desktop. Yay!

Also gathered up locations of documents for study including an example of audio playback via OpenAL. The goal is to be able to output my audio over OpenAL, via LWJGL.

 5 
 on: 2016-08-25 04:31:13 
Started by purenickery - Last post by purenickery
Alright, it's been quite a while since I updated the devlog, so I'm just going to do a quick run-down of what's been going on over the past few months.

First bit of exciting news is our artist, Cody, moved in to the apartment with me so we can work on the game together, which is a great help.

I have been working on a new and improved editor for the game and mods that should be super accessible and easy to use (I have already posted about this but it's gone through many improvements). I added some new data types to help with particle editing, such as:
Click to Play


Also after a bunch of banging my head on a table I have live previews of various things in the editor:
Click to Play




Many of the things I've worked on this year have been things I really should have done from the beginning. But I was a much less experienced programmer back then. Now I know better for the future! One of the things I should have done from the beginning is 16x16 tiles, which I implemented the other day. It makes the game look much more varied and alive:
Click to Play



Last piece of news I will share today (I've been working on a lot of other things of course, but I will share those in separate posts) is the new inventory system. We already modified it so items could be different sizes, but I recently implemented a feature where items don't have to take up all their slot spaces, and item images can overflow over the slot spaces they occupy. Hopefully it will make the inventory look more full and allow for better management of items.
Click to Play


Click to Play



And, like always, all of these tools will be available to modders!

 6 
 on: 2016-08-24 23:52:49 
Started by philjord - Last post by gouessej
Yes, it exists thanks to philjord and thanks to JOGL 2 (Java3D >= 1.6.0 exclusively relies on JOGL). Java3D 1.7.0 will include his OpenGL ES pipeline. As philjord said, Java3D is tightly bound to AWT, making it work with NEWT requires some deep redesign but it allows to share a lot of source code on mobile and desktop environments, the OpenGL ES pipeline will probably be usable not only under Android. This is the fulfilment of our vision in the JogAmp community, a single set of tools to target all major operating systems in mobile and desktop environments, and that's the main reason why JOGL has its own windowing toolkit.

philjord's stuff is impressive  Grin

 7 
 on: 2016-08-24 23:12:40 
Started by TumultuousSys - Last post by Gjallar
Your project seems pretty impressive and I'm sure a lot of people would love to take a look at it, but you are salting your own soup with those ad-fly links.

 8 
 on: 2016-08-24 22:44:05 
Started by BurntPizza - Last post by lcass
Got my new renderer working and my god it is so much simpler to use , GUI's and stuff are still a *bit* of a challenge requiring a seperate set of buffer storage. It would be great to know how people usually handle modular layering.

 9 
 on: 2016-08-24 21:40:38 
Started by philjord - Last post by philjord
Only in my private git repo Sad

But as the official maintainer of Java3D my intention is to try to get a version of it released at some point in the future.

Though it is a nightmare of biblical proportions as Android has no awt and Java3D is based on awt, so there's a lot of "mess"


And congratulations on getting Naroth released, it looks fantastic!

 10 
 on: 2016-08-24 21:31:10 
Started by philjord - Last post by EgonOlsen
It uses Java3D and JBullet.
Java3D on Android... Huh Such a thing exists?

Pages: [1] 2 3 ... 10
 
roseslayer (413 views)
2016-08-06 11:43:29

roseslayer (376 views)
2016-08-06 09:43:11

xTheGamerCodes (451 views)
2016-08-04 15:40:59

xTheGamerCodes (445 views)
2016-08-04 15:40:24

orrenravid (796 views)
2016-07-16 03:57:23

theagentd (871 views)
2016-07-11 14:28:54

Hydroque (967 views)
2016-07-06 05:56:57

Hydroque (989 views)
2016-07-03 08:52:54

GrandCastle (802 views)
2016-07-01 09:13:47

GrandCastle (637 views)
2016-07-01 09:09:45
Rendering resources
by Roquen
2016-08-08 05:55:21

Rendering resources
by Roquen
2016-08-08 05:52:42

Rendering resources
by Roquen
2016-08-08 05:50:38

Rendering resources
by Roquen
2016-08-08 05:49:53

Rendering resources
by Roquen
2016-08-08 05:32:39

Making a Dynamic Plugin System
by Hydroque
2016-06-25 00:13:25

Java Data structures
by BinaryMonkL
2016-06-13 21:22:09

Java Data structures
by BinaryMonkL
2016-06-13 21:20:42
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!