Jump to content

  • Log In with Google      Sign In   
  • Create Account

Ryan_001

Member Since 23 Apr 2003
Offline Last Active Yesterday, 08:07 PM

#5285793 Should getters and setters be avoided?

Posted by Ryan_001 on 08 April 2016 - 07:47 AM

As usual, you should not take everything too seriously.

 

There is a common behavioural pattern of someone doing something, then someone else noticing that it's actually a clever idea and calling it "best practice". Then someone calls it a "pattern", and soon a witch hunt starts against anyone not applying the pattern. A year later, someone says "considered evil" and the word "antipattern" comes up, and the same witch hunt starts in the opposite direction. And then, another year later, someone says "no longer considered evil".

I can't upvote this enough ; )




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

Posted by Ryan_001 on 03 April 2016 - 10:12 AM

The biggest advances will not be in visual rendering (IM very HO) but rather in physics and gameplay/simulation.  Simulating battles with millions of entities, realistic fluid interaction, building destruction, etc...




#5283047 Looking for a *.dds texture loading library in C++ that isn't specific to...

Posted by Ryan_001 on 23 March 2016 - 08:43 PM

WIC supports DDS files as well: https://msdn.microsoft.com/en-us/library/windows/desktop/ee719654(v=vs.85).aspx




#5281656 Brace yourself, Shader Model 6.0 is coming

Posted by Ryan_001 on 17 March 2016 - 07:27 AM

When they said procedural textures I was thinking something else, but this does look interesting none-the-less.

 

What I want to see...  I'll call 'sampler shaders'.  Instead of using a normal sampler, you could create and use a 'Sampler Shader'.  When the GPU gets to the point in a shader where it needs to sample a texture, it would stop (conceptually only) and execute the samper shader.  The sampler shader would be executed over a range (say a 16x16 or 32x32 block, whatever the driver/hardware thinks is necessary) to produce unfiltered texels which would be stored in a cache (type, size, policies, etc... would be driver handled).  The shader performing the sampling would then be able to read from the cache, perform whatever filtering is necessary, and continue on.  The sampler shader would have a minimum blocking size (much like a compute shader) and access to on-chip shared memory.  This way complex procedural texture data could be created and used in real-time, dynamically adjusting its resolution/quality based on its usage in the scene.  Not only procedural texturing but higher quality texture compression (wavelet, VQ, fractal, whatever), would be rather trivial...

 

Alas this seems to be something else... /sigh




#5281601 Template madness - template operator not found

Posted by Ryan_001 on 17 March 2016 - 01:45 AM

This works in VS2015:

# include <cstdint>
# include <iostream>
# include <vector>
# include <type_traits>
# include <string>


using namespace std;

template<typename T> class A {
	public:

		// internal B
		template<size_t x> class B {
			T asdf[x];
			};

		template<typename T> struct IsTypeB { 
			static const bool value = false;
			static const size_t size = 0;
			};

		template<size_t x> struct IsTypeB< B<x> > { 
			static const bool value = true;
			static const size_t size = x;
			};

		// internal C
		template<size_t x> class C {
			T asdf[x];
			};

		template<typename T> struct IsTypeC { 
			static const bool value = false;
			static const size_t size = 0;
			};

		template<size_t x> struct IsTypeC< C<x> > { 
			static const bool value = true;
			static const size_t size = x;
			};
	};

//template<typename T, Size x> inline A<T> operator+(T value, const typename A<T>::template B<x>& vec ) {
//	return A<T>();
//	}

template<typename T0, typename T1> 
	auto operator+(T0 v, const T1&  x) -> typename std::enable_if< A<T0>::IsTypeB<T1>::value , A<T0> >::type {
	cout << "size of B<x> = " << A<T0>::IsTypeB<T1>::size << endl;
	return A<T0>();
	}

template<typename T0, typename T1> 
	auto operator+(T0 v, const T1&  x) -> typename std::enable_if< A<T0>::IsTypeC<T1>::value , A<T0> >::type {
	cout << "size of C<x> = " << A<T0>::IsTypeC<T1>::size << endl;
	return A<T0>();
	}

	
// ----- main -----
void main() {

	A<float>::B<2> b;
	A<float>::C<3> c;

	5.0f + b;
	6.0f + c;

	cout << "done" << endl;

	getchar();
	}

As Pink Horror pointed out you're not gonna be able to deduce A<T1>::B<T2> directly. But you can 'hoist' it into the main class then use SFINAE to filter functions as necessary.




#5277033 How fast is hardware-accelerated ray-tracing these days?

Posted by Ryan_001 on 19 February 2016 - 04:08 PM

 

You'd have to perform the vertex animation, apply it to the mesh, then take the mesh triangles and build an oct-tree/BVH heirarchy/binary-tree/sort into grid cells/whatever?


Like a character? Precompute a static BVH for the character in T-Pose. At runtime keep the tree structure but update the bounding boxes.
The animated tree might not be as good as a completely rebuild tree but still pretty good.
If you have 100 Characters you only need to build a tree for those 100 root nodes.
I'm using it for a realtime GI solution i'm working on for many years now.
Don't know any papers but i'm sure i'm not the inventor of this simple idea smile.png

 

Interesting...  You don't find there are too many triangles in your leaf BVH nodes?




#5277024 How fast is hardware-accelerated ray-tracing these days?

Posted by Ryan_001 on 19 February 2016 - 03:07 PM

While that's common opinion in graphics community, i disagree.

Say you have 10000 dynamic objects: Prebuild a tree per object, and at runtime build a tree from only 10000 nodes, that's <1 ms on GPU.

Research projects rebuild the entire tree every frame, thus they often show similar time for building and tracing.

 

For simple linear transformations that is pretty straight forward, but what do you do about more complex animations?  You'd have to perform the vertex animation, apply it to the mesh, then take the mesh triangles and build an oct-tree/BVH heirarchy/binary-tree/sort into grid cells/whatever?  In all the papers I've read this part is very slow even when performed in parallel.  It also undermines your raytracing time complexity, doing an O(n) prepass before an O(log(n)) final trace still yields an O(n) algorithm (granted there's more to algorithms than just big O time complexity...).

 

Course if you have any papers, evidence, or experience to prove me wrong (and don't take my tone wrong, I'm not trying to be argumentative, I really enjoy reading the latest up-to-date papers and seeing videos of this stuff) I would LOVE to read/see them :)  I love raytracing and I have a few ideas of my own I want to try when I get some time.




#5276951 How fast is hardware-accelerated ray-tracing these days?

Posted by Ryan_001 on 19 February 2016 - 09:00 AM

My understanding is that the ray tracing isn't really the hard part.  Its building the data structure that is the issue.  Whether you're using a BVH, oct-tree, binary tree, grid, or something else, the data structure is essential since it allows you to move your tracing time complexity from O(n) to O(log(n)).  So for large enough static scenes, ray tracing can actually beat out standard triangle rasterization.  The problem is building that data structure in real time.  Sure simple linear transformations within certain limitations can be handled relatively quickly, but vertex skinning, dynamic vertex displacement (like animated water), anything stretching/oozing, many particle effects, basically animation, is what really is the bottleneck at this point.

 

Really the problem should be re-stated, its not how fast GPUs can raytrace these days, its how fast can they build the raytracing data structure these days.




#5275986 instancing with multiple meshes

Posted by Ryan_001 on 16 February 2016 - 11:58 AM

One technique I used for drawing a large number of small mesh's was to abuse the tessellator. This of course won't work for D3D9 level hardware, but I thought I'd mention it none-the-less.

In the vertex shader I computed all the per-instance data (one vertex per instance). The hull shader computed the number of triangles needed for the given instance and created a quad patch with enough triangles to render all the triangles in the mesh. The Hull shader did nothing but pass on the per-instance data. The geometry shader would then transform each triangle created from the tessellator using the per-instance data passed in, and looking up the specific instances vertex data from a SRV. It did mean duplication of some vertex computations, but it also meant that you got very efficient culling/LOD, and that per-instance data only needed to be calculated once, and there was no intermediary UAVs, streams outs, etc...

Now I never benchmarked the performance, and after watching the wonderful link by Phantom I have a feeling that it would probably be slower than other options, but it seemed pretty cool at the time smile.png


#5273932 Cost of Switching Shaders

Posted by Ryan_001 on 02 February 2016 - 02:18 PM

I don't think so. AFAIK, D3D11's cmd list recording is all done in the user-mode library, and doesn't actualy call into the driver until you submit the list.


It does state in the documentation "Pre-record a command list before you need to render it (for example, while a level is loading) and efficiently play it back later in your scene. This optimization works well when you need to render something often.". I've also seen it stated (though I don't remember exactly where) that the driver can perform some optimizations on the command list, and that the user-mode library is only used when the driver doesn't support it.


#5273350 Warning conversion from size_t to int in x64

Posted by Ryan_001 on 30 January 2016 - 09:00 AM

-


#5273237 Warning conversion from size_t to int in x64

Posted by Ryan_001 on 29 January 2016 - 01:12 PM

Seems this has turned into a signed vs unsigned debate. I'm quite curious on other's take on it. I've always leaned towards the 'unsigned as length/size' approach, but I'm curious as to other's choice/rational.


#5272784 Loading images in DirectX 11 to use as textures and sprites

Posted by Ryan_001 on 26 January 2016 - 07:57 PM

You can use directxtex, a loader that can load dds and other graphics files or you can use WIC. WIC is windows own image loading library which is pluggable, so if windows can load that format so can you if you use WIC.

In one of my games I used WIC to load sprites and textures from png files.

This isn't the most efficient way to do it and you're better off converting to dds or a format that closely matches the memory format of the image as part of your build process as this means less parsing to load assets, but png is friendly to modding so that's why I chose it.

Have fun!


I've used WIC successfully as well. Its not 'optimal' but still a solid route, and very easy I might add.


#5272059 Unique ID per type

Posted by Ryan_001 on 20 January 2016 - 03:43 PM

  • From the most pedantic point of view, using the __func__ hack even makes your program a little more robust. The typeid operator does not guarantee that the same type_info object is returned for different invocations in the same program with the same type. This sounds like something you could take for granted, and this is probably what happens anyway, but in the strictest sense, that's not the case. The standard merely says that some type_info (or derived) object with static storage duration is returned (and leaving unspecified whether destructors are called), and that the objects from different typeid expressions with the same type compare equal. That doesn't mean that they are equal, or that that name() returns the same value (or even the same pointer).

 

Isn't this the entire point of type_index, so that type_index's made from different typeid's to the same type do compare equal?  From my understanding the real issue with type_info's being different for different types becomes relevant when were talking same types used from different dll's.




#5271832 C++

Posted by Ryan_001 on 19 January 2016 - 08:50 AM

I also recommend anything by Scott Meyers, he's fantastic at taking complex idea's and explaining them in simple terms without losing sight of the overall picture.




PARTNERS