Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Mar 2009
Offline Last Active Today, 07:29 AM

#5287998 Depth Problem In Release Mode

Posted by Krypt0n on 21 April 2016 - 10:40 AM

1. add "while(true){Sleep(0);}" at the beginning of "main"

2. start the application externally

3. attach the debugger

4. break at the Sleep

5. set the next line as the point to continue the execution (right click context menu)

6. debug what's different :)

7. fix it

8. transfer out of gratefulness all your moneyz to my account (that's optional, but 7. might break if you don't.)

#5286654 Occlusion culling w/o a Zbuffer

Posted by Krypt0n on 13 April 2016 - 07:55 AM

zbuffer ist actually less accurate (if lower resolution, which is the common case) and has more corner cases (e.g. you need water tight rendering, deal with z-fighting issues etc.)

Hadn't thought about z-fighting, and I was thinking full size gpu occlusion so I hadn't thought of that.  What do you by "mean water tight rendering", I've heard the term before but don't remember what it means?

z-fighting happens if you use e.g. lower LODs for occlusion culling (which makes sense if you think about it, as you just test, but you don't care about the visuals). The problem pops up if you e.g. have a picture on the wall (flat poly) and some LOD of the wall/room is used which is not 100% fitting the higher poly that is rendering close up.

water tight rendering is, when you don't have pixel-gaps between triangles of a mesh. Equally important is to not "over-draw" edges twice. you'd notice this on transparent triangles where edge-pixel blend twice.
this is especialyl important on occlusion culling, as one pixel-gap will "un-hide" everything behind and all occlusion culling was a waste of time. similar drawing too much will lead to occlusion in places you don't want to.

#5286507 DirectX 11 Volume Rendering Advice Needed

Posted by Krypt0n on 12 April 2016 - 12:32 PM

more efficient and simpler would be to do all in one pass.
render just the back faces, calculate with a simple ray intersection the near-distance of the cube (if t<0.0, then t=0.0); and trace through the volume.

#5286265 Occlusion culling w/o a Zbuffer

Posted by Krypt0n on 11 April 2016 - 04:31 AM

I know a zbuffer is easier more accurate and there are no corner cases with it but I am curious about this.

zbuffer ist actually less accurate (if lower resolution, which is the common case) and has more corner cases (e.g. you need water tight rendering, deal with z-fighting issues etc.)

the bad side of occlusion volumes is that these are disconnected, hence just fully occluded object will be removed, objects crossing several occlusion volumes will stay, although in reality invisible.
one solution to this is "occluder fusion", but that's where math become dirty. (actually, not the math, but dealing with all the float precision issues.)

#5285612 Planet Rendering: Spherical Level-of-Detail in less than 100 lines of C++

Posted by Krypt0n on 07 April 2016 - 12:14 PM

Your bezier and subdivision samples look nice. I wonder if its easy to make it to a recursive approach (looks like uniform subdivision in the screenshots)

the subdivision (catmull clark) is recursive. it's used in the Reyes rendering.
it's a really elegant algorithm.

1. Yes, due to normalizing it does not work immediately for the current code, but you could use  a displacement map and combine rendering with a tessellation shader.

there goes all the challenge ;)
there was a nice paper about subdivision:

#5285557 Planet Rendering: Spherical Level-of-Detail in less than 100 lines of C++

Posted by Krypt0n on 07 April 2016 - 03:29 AM

really neat :)

you still have gaps/t-junctions, you should evaluate if the tessellation is needed on the center of the edges and based on that create triangles.
something like
uint32_t edge0 = NeedSubdivide((V0+V1)/2);
uint32_t edge1 = NeedSubdivide((V1+V2)/2);
uint32_t edge2 = NeedSubdivide((V2+V0)/2);
case 0:
//no subdivision, spit out triangle
case 1:
//the way you subdivide now
(there is a way more elegant way to solve this,I won't spoil this puzzle :) )

1. I think it doesn't work out of the box with all meshes. you need to normalize the distances to center, which limits this to sphere.
				p[idx[3 * i + 0]].norm(), 
				p[idx[3 * i + 1]].norm(),
				p[idx[3 * i + 2]].norm(),
to apply it on all meshes, something simple to get running is either bezier patches (which nicely works per patch, but is not recursive).
my old attempt http://imgbox.com/qVkijDlM (timestamp says it's from 1996 :o)
or try catmul clark, which is simple, but works always on the whole mesh (closing t-junctions works similar to the tetraheder->sphere subdivision)
that was my attempt:

2. yeah, had a feeling like it might be for planetary walking. you should make a fly-through, from space to surface, with tessellation :)

#5285411 Planet Rendering: Spherical Level-of-Detail in less than 100 lines of C++

Posted by Krypt0n on 06 April 2016 - 05:23 AM

it's a good start, you should give it a few more iterations.

1.there is a simpler way to tessellate to a sphere, starting with a tetrahedron (4 triangles) and halving the edges of the triangles at every step.
your tessellation has the classical t-junction issue, which usually takes the most code to fix. with tetrahedrons, when you evaluate per-edge, it's actually very simple to get a closed mesh.

2.usually you would increase the tessellation at the silhouette, not at the center (but that decision probably depends on a lot of factors)

#5284995 In terms of engine technology, what ground is left to break?

Posted by Krypt0n on 04 April 2016 - 03:42 AM

IMHO biggest ground to break is to free people from doing the same as others do.
Over the years technology got more and more unified, everyone writes PBR rendering, uses the same shadow tech, same content creation pipelines.

it's really gets boring to watch (I mean the actual games) and when you see that the "research" co-workers do is googling how someone else solved the problem and re-implementing it like juniors do.
This often boils down to pressure of having to fill out the same check-boxes as competitors do, and to go the safe path, because production is expensive.

I liked the time when we had rasterizers vs raycasters, volume shadows vs shadowmaps, realtime lights vs baked lightmaps vs PTR, etc. (e.g. look at GI for realtime objects in HL2, it's not a pre-baked SH like in all games nowadays, they raycasted to 6direction. imo that's super amazing, ...)
nowadays it's so uniform, even the implementations are equal. because there is just one way of pre-integrating BRDFs, one way of importance sampling, one way of creating uniform distributed rays, and everyone has to drop anisotropy and sample cubemaps....

that's why I'd love to see us to move engines into unique directions, even if it is crazy, like Megatextures, or objectspace lighting, or...

#5284627 Wondering how to build a somewhat complex UI...

Posted by Krypt0n on 01 April 2016 - 11:10 AM

Another important concept is the delegate. In my case this is just a struct with a collection of std::function callbacks that respond to events for each type of widget. This is way better than the inheritance solutions required by many GUI toolkits.

are you hooking up those delegates somehow automatically, or by hand?
it is always a little bit worrying to me to maintain it by hand, as one missed "free" and you have a call to a wild pointer.
but I also dislike using external "generator" tools like in Qt that generate binding-code (as I'd prefer to have it all self-contained).

I admit, I'm a very bad tools/ui coder. A good starting point to improve I guess :). Has anyone suggestions for books to buy? there are tons to learn Qt, wxWidgets etc. but barely focus on gamedev. I've bought some ages ago "3D Games" [Policarpo] because of the UI code, which showed some nice basics, but wasn't really going into depth.
(sorry for slightly highjackin this thread)

#5284367 How To Build Your Console

Posted by Krypt0n on 30 March 2016 - 05:21 PM

reminds me of http://www.xgamestation.com/view_product.php?id=33

they're selling very basic console hardware and all the stuff you need to learn how to program these and how they work.



seems like they've moved, but they offer still the same set of small consoles:


#5283825 resolution scaling

Posted by Krypt0n on 28 March 2016 - 04:40 AM

perfect timing for quantum break :)
apparently they're rendering 720p MSAA4x (hence 2560x1440) and using temporal upscaling from the last 4 frames scale up to 1080p.

kind of remind me of Quincunx.

in some games, I've been rendering MSAA4x for transparent/blended surfaces, on top of native rendered pixel. Not sure how that resolution would need to be called.
But resolution is often a marketing thing, when games don't really have anything else to shine, especially console ports for PC.

#5283538 Object Space Lightning

Posted by Krypt0n on 26 March 2016 - 04:51 AM

The advantage of spare textures is that you could apply lighting/shading more selective. Without it, you have to select one resolution for an object, which can be problematic if these are of irregular size on the screen. (it's probably fine for an RTS). If you render some indoor for an FPS, you might stand close up to a wall, but you might not even see the back side of that object.

With spare texture, you could spawn some compute jobs to shade the visible parts (which get reported with the GPU at per-pixel level), and skip shading all invisible parts.


This is not mandatory to get object space shading running, but a very nice optimization.

#5281343 Game Optimization

Posted by Krypt0n on 15 March 2016 - 09:19 AM

it's not even for performance reasons, but required to make your code work properly e.g.

if(pCamera!=nullptr && pCamera->IsActive()==true)...

you don't want the 2nd statement to be always evaluated, as it would lead to a memory access violation.

#5280170 Has anyone ever ported a ps2 game to pc?

Posted by Krypt0n on 08 March 2016 - 08:54 AM

Also, if you don't have source code, then give up right now. I was once part of a PS2->PS3 porting project where the original developer lost the source code, and we had to abandon the project; trying to resurrect a game via decompiling MIPS disassembly is the worst thing ever when you have a tight budget and schedule.

If you're in this situation, use an emulator and call it quits.

was in a similar situation. It's really shocking how many devs just loose source code, sometimes just some "ex employee might have a copy on a floppy, you can mail him maybe".


I've ported a PSP binary to a C# platform, emulators not really available and performance wise might not deliver. My solution was to convert the assembler dump to c# code (it's quite scary if you notice how many "doubles" were used which the HW back then could not handle and it ran in emulation function.

my optimization pass was to find code blocks (branch target to return with time stamps added by the conversion tool) that were small and expensive and rewrite these with native c# code.

#5278802 Tips for keeping a graphics heavy game in 60fps?

Posted by Krypt0n on 01 March 2016 - 02:12 AM

This is a profiling question, so step 1 is always: take measurements.


most people start with random tweaks when they want to improve performance. some "stupid" ideas turn out good, while others don't, but because there was never a profiling, you don't know why and neither if there was a simpler/smarter way.

profile profile profile.
once you see what is going on, it starts to become approachable.