Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


BlueSpud

Member Since 17 Jul 2013
Offline Last Active Aug 02 2015 12:29 PM

#5208796 Cascaded Shadow Maps Look Bad

Posted by BlueSpud on 04 February 2015 - 07:48 PM

I don't understand what there's so much confusion.

I don’t understand why you think anyone here is confused. No one here needs an explanation on how cascaded shadow maps work.
We’ve both very clearly explained that you are the one who is using them wrong.We both very clearly understand that you are using fixed distances from the camera to decide where to place each cascade and that by doing this you can walk certain distances you can position the house entirely within a single cascade.
We both understood this very clearly before you ever misunderstood what we were saying, so now that it is very very clear that you are the one who hasn’t understood, why don’t you go back and read what we said, and keep reading it until you understand?
Hint:
while ( beliefThatLSpiroOrHodgmanMisunderstands == true ) { ReadTheirPostsAgain(); }
 
Hint: The blue text might be the key to your misunderstanding, and might be exactly the thing Hodgman was saying is the problem.  Hint hint?
 
 
I also mentioned pixel density.  That would be what I would investigate.
 
 
L. Spiro
I have no doubt that he understands cascaded shadow mapping. What I had said in the original post was that each screenshot only showed one cascade. He misunderstood that and thought I was only sampling from one shadow map at a time, instead of all 3. I guess I was ambiguous again, and I didn't mention all 3 cascades were present so I clarified one last time. Then you came in and added to the confusion. While your technically right that not all cascades are really showing, they are present which is very different. I'll look into pixel density and rendering the house bigger, but everything else you said had noting to do with the problem.


#5200119 Best Lighting Approach

Posted by BlueSpud on 26 December 2014 - 01:58 PM

Thank you very much.
I already feared this answer as I saw how many lightning techniques there are.

Your Google tips are worth a mint in the internet age smile.png
Very useful thanks, wouldn't have come up with that by myself.
Many tutorials I read about this (including stuff from Valve and way to technical stuff from NVidia) always stated that it only works by preprocessing it and not on the run.

The technique of deferred shading goes right in the direction of my own idea which is always nice to see.

Just a question according this:
A render target uses a texture as a storage. However video cards support in general a texture size of 1024×1024 with a screen resolution of 1920x1080 at the same time.
> How can I create a texture of the size of the screen for deferred shading?
- When splitting the screen size in multiple textures I would obviously need to draw the scene n-times in every buffer.
What am I missing? :-?

Video cards aren't necessarily limited to the 1024 x 1024. You create multiple render targets, and then use a shader to render out to each buffer. This way you only have to take one pass rendering out the GBuffer. OpenGL and GLSL this is really easy, but I have no idea how directX works, but I'm sure its possible. Theres a lot of different kinds of deferred shading out there, and depending on how involved you want to get, tile-based deferred shading is going to be your best bet. I don't know where you read that, but its probably years old. 

 

Good luck.




#5196812 Using SDL, OpenGL and Qt Together

Posted by BlueSpud on 07 December 2014 - 11:56 AM

For a while I've been using SDL to write my 3D engine,and have recently been implementing an editor that can export an optimized format for the type of engine Im building. Right now the editor is fairly simple, objects can just be moved around and their textures and models can be changed. As of right now, I'm using SDL with OpenGL to render everything, but I want to use Qt for the GUI part of the editor, that way it looks native on every platform. I've got it working great so far, I'm running a QApplication inside of the SDL application, so it basically just opens 2 windows, one that uses SDL and OpenGL, and the other using Qt. Doing a bit of research, I've found that you can manually update a QApplication, which totally removes any threading problems, and everything works. Just in case you're having a hard time visualizing this, heres a picture:

prbjc.jpg

What my goal is to merge these windows into one, because on smaller screens (like my laptop's) it makes it really hard to keep track of all the different windows that I would eventually have. I know theres a way to render to Qt with OpenGL, but can this be integrated with SDL? Am I going to need to move away from using an SDL window and use a QT one if the editor is enabled? Just to clarify, when the engine isn't in editor mode, it won't use and Qt, just SDL, so optimally I wouldn't need to do this.

Thanks.




#5172139 Inertia Causing Extremely odd effects.

Posted by BlueSpud on 07 August 2014 - 03:42 PM

 

That's weird. Could you try to replace your main / WinMain method with this code just to test whether you get correct results with minimal code?

And of course you'll need to fix Bullet paths.

#include <iostream>
using std::cout;
#include <DirectXMath.h>
using DirectX::XMFLOAT3;
#include "../Bullet Physics/btBulletCollisionCommon.h"
#include "../Bullet Physics/btBulletDynamicsCommon.h"
#pragma comment(lib, "../x64/Debug/Bullet Physics.lib")

btRigidBody* addRigidSpehere(float rad, XMFLOAT3 position)
{
	btTransform t;
	t.setIdentity();
	t.setOrigin(btVector3(position.x, position.y, position.z));

	btSphereShape* sphere = new btSphereShape(rad);

	//calculate inertia
	btVector3 inertia(0.0, 0.0, 0.0);
	sphere->calculateLocalInertia(1.0, inertia);

	btMotionState* motionState = new btDefaultMotionState(t);
	btRigidBody::btRigidBodyConstructionInfo info(1.0, motionState, sphere, inertia);
	btRigidBody* sphereBody = new btRigidBody(info);

	return sphereBody;
}

void main() {
	auto bulletConfiguration = new btDefaultCollisionConfiguration();
	auto bulletDispatcher = new btCollisionDispatcher(bulletConfiguration);
	auto bulletBroadPhaseInterface = new btDbvtBroadphase();
	auto bulletSolver = new btSequentialImpulseConstraintSolver();

	auto bulletWorld = new btDiscreteDynamicsWorld(bulletDispatcher, bulletBroadPhaseInterface, bulletSolver, bulletConfiguration);
	bulletWorld->setGravity(btVector3(0, -10, 0));

	btTransform t;
	t.setIdentity();
	t.setOrigin(btVector3(0, 0, 0));

	btStaticPlaneShape* plane = new btStaticPlaneShape(btVector3(0, 1, 0), 0.0);
	btMotionState* motionStatePlane = new btDefaultMotionState(t);
	btRigidBody::btRigidBodyConstructionInfo info(0.0, motionStatePlane, plane);
	btRigidBody* planeBody = new btRigidBody(info);

	bulletWorld->addRigidBody(planeBody);

	auto sphere = addRigidSpehere(1, XMFLOAT3(0, 3, 0));
	bulletWorld->addRigidBody(sphere);

	while(1) {
		bulletWorld->stepSimulation(1.0 / 60.0);
		cout << sphere->getWorldTransform().getOrigin().getX() << ", ";
		cout << sphere->getWorldTransform().getOrigin().getY() << ", ";
		cout << sphere->getWorldTransform().getOrigin().getZ() << "\n";
	}
}

No, same thing. Heres the output:

0, 2.99722, 0
0, 2.99167, 0
0, 2.98333, 0
0, 2.97222, 0
0, 2.95833, 0
0, 2.94167, 0
0, 2.92222, 0
0, 2.9, 0
0, 2.875, 0
0, 2.84722, 0
0, 2.81667, 0
0, 2.78333, 0
0, 2.74722, 0
0, 2.70833, 0
0, 2.66667, 0
0, 2.62222, 0
0, 2.575, 0
0, 2.525, 0
0, 2.47222, 0
0, 2.41667, 0
0, 2.35833, 0
0, 2.29722, 0
0, 2.23333, 0
0, 2.16667, 0
0, 2.09722, 0
0, 2.025, 0
0, 1.95, 0
0, 1.87222, 0
0, 1.79167, 0
0, 1.70833, 0
0, 1.62222, 0
0, 1.53333, 0
0, 1.44167, 0
0, 1.34722, 0
0, 1.25, 0
0, 1.15, 0
0, 1.04722, 0
0, 0.941667, 0
-0.00136054, 0.988333, 0
-0.00399887, 0.990667, 0
-0.00721497, 0.992533, 0
-0.0110322, 0.994027, 0
-0.0154692, 0.995221, 0
-0.0205409, 0.996177, 0
-0.0262592, 0.996942, 0
-0.0326338, 0.997553, 0
-0.0396722, 0.998043, 0
-0.0473806, 0.998434, 0
-0.0557639, 0.998747, 0
-0.064826, 0.998998, 0
-0.07457, 0.999198, 0
-0.0849984, 0.999359, 0
-0.0961132, 0.999487, 0
-0.107916, 0.99959, 0
-0.120408, 0.999672, 0
-0.133591, 0.999737, 0
-0.147464, 0.99979, 0
-0.16203, 0.999832, 0
-0.177288, 0.999865, 0
-0.193238, 0.999892, 0
-0.209882, 0.999914, 0
-0.227219, 0.999931, 0
-0.24525, 0.999945, 0
-0.263974, 0.999956, 0
-0.283393, 0.999965, 0
-0.303505, 0.999972, 0
-0.324311, 0.999977, 0
-0.345812, 0.999982, 0
-0.368007, 0.999986, 0
-0.390896, 0.999988, 0
-0.414479, 0.999991, 0
-0.438757, 0.999993, 0
-0.463729, 0.999994, 0
-0.489395, 0.999995, 0
-0.515756, 0.999996, 0
-0.542811, 0.999997, 0
-0.570561, 0.999998, 0
-0.599005, 0.999998, 0
-0.628143, 0.999998, 0
-0.657976, 0.999999, 0
-0.688503, 0.999999, 0
-0.719725, 0.999999, 0
-0.751641, 0.999999, 0
-0.784252, 1, 0
-0.817557, 1, 0
-0.851556, 1, 0
-0.88625, 1, 0
-0.921638, 1, 0
-0.957721, 1, 0
-0.994498, 1, 0
-1.03197, 1, 0
-1.07014, 1, 0
-1.109, 1, 0
-1.14855, 1, 0
-1.1888, 1, 0
-1.22975, 1, 0
-1.27138, 1, 0
-1.31372, 1, 0
-1.35674, 1, 0
-1.40047, 1, 0
-1.44488, 1, 0
-1.48999, 1, 0
-1.5358, 1, 0
-1.5823, 1, 0
-1.62949, 1, 0
-1.67738, 1, 0
-1.72596, 1, 0
-1.77524, 1, 0
-1.82521, 1, 0
-1.87588, 1, 0
-1.92724, 1, 0
-1.97929, 1, 0
-2.03204, 1, 0
-2.08549, 1, 0
-2.13962, 1, 0
-2.19446, 1, 0
-2.24998, 1, 0
-2.30621, 1, 0
-2.36312, 1, 0
-2.42073, 1, 0
-2.47904, 1, 0
-2.53804, 1, 0
-2.59773, 1, 0
-2.65812, 1, 0
-2.7192, 1, 0
-2.78098, 1, 0
-2.84345, 1, 0
-2.90662, 1, 0
-2.97048, 1, 0
-3.03503, 1, 0
-3.10028, 1, 0
-3.16623, 1, 0
-3.23286, 1, 0
-3.3002, 1, 0
-3.36822, 1, 0
-3.43695, 1, 0
-3.50636, 1, 0
-3.57647, 1, 0
-3.64728, 1, 0
-3.71878, 1, 0
-3.79097, 1, 0
-3.86386, 1, 0
-3.93744, 1, 0
-4.01172, 1, 0
-4.08669, 1, 0
-4.16236, 1, 0
-4.23872, 1, 0
-4.31577, 1, 0
-4.39352, 1, 0
-4.47197, 1, 0
-4.5511, 1, 0

It would seem that my issue is actually a compilation error, its listed in the bit hub here:

https://github.com/bulletphysics/bullet3/issues/49

I've been trying to compile bullet 3 as a .framework like I had done for 2.82, but to no avail. 

 

EDIT: luckily they posted the fix in a commit, so I was able to go into 2.82 and modify the code causing an issue, works like a dream now.




#5116384 Questions about mesh rendering performance

Posted by BlueSpud on 11 December 2013 - 08:14 PM

I was under the impression that Draw Lists were the fastest.

Your power level of mistaken…it’s over 9,000!!!
 

I am using shaders, just not for textures.

Why would you do that? Why would you ever mix fixed-functionality and programmable pipelines? Are you maintaining 2 separate lighting pipelines?
 

As for not using other aspects of modern OpenGl, I want to have this run on lower end computers.

You are aware that any version of OpenGL that supports shaders (which you are using) also supports VBO’s and IBO’s, right?
VBO’s and IBO’s have been core since OpenGL 1.5.
Shaders have been core since OpenGL 2.0.
In short, your excuse about compatibility makes no sense and it doesn’t make sense to discuss performance issues until you start using VBO’s and IBO’s.
Ask again when you have switched to VBO’s and IBO’s (and preferably shaders for anything, not just “everything but textures”).
L. Spiro
Maybe I was not specific enough. I have a deferred lighting system in place, so I am not using the fixed functionality lighting. I render it in several passes, one being the albedo. I use shaders for all the other passes except that. I simply don't use a shader for that pass because binding program 0 yields the same results as creating a simple shader to render geometry with texture. If just using a simple shader is faster, it would be easy to create a shader to do that, I would do it but I haven't been able to notice a difference.

As for the draw lists vs the vertex buffer objects, I was unaware that vbos were in the older OpenGL versions and I thought it was added it 3.2. I've tried both vertex buffer objects and display lists. Based on my experiences, draw lists are significantly faster, and I've also seen that on the internet. It could just be my video card though. I've also read that internally, the data is stored the same way as vbos in some cases. To me they just seem easier to implement and control, but that's just my opinion. The preformence problem might be somewhere else, and I'll see if I can track that down. Thank you for your input.


#5082832 opengl game

Posted by BlueSpud on 03 August 2013 - 03:16 PM

 

so I should use a vector? I am somewhat familiar with vectors.

It depends, you could make your own linked list, but only if it is absolutely necessary. The std::vector does have some overhead, but shouldn't be noticable for this game.

 

If he stored the textures outside the object, just not drawing them and still allocating the RAM for each invader wouldn't be a big deal, he could just clear the vector at the end of the level and it wouldn't be a huge performance problem. 




#5081710 opengl game

Posted by BlueSpud on 30 July 2013 - 08:23 AM

well I am attempting to render the aliens on the screen, I want to draw the alien to the screen and move to the right and then erase the sprite and draw a new  sprite and moves the sprite to the right again. basically I want to draw a sprite and erase it and redraw a different sprite and then erase it and then draw the previous sprite and have all the sprite to move to the right.

Thats not exactly what you want to do. Create an object for each alien:

class Invader
{
public:
float x,y,z;
void update()

};

Then create the invaders in whatever way you want best to handle them.

Make a callback for glutIdleFunc().

Put in that callback:

//call onUpdate() for all the invaders
updateInvaders()
//draw a new frame
glutPostRedDisplay();

In the onUpdate() for the invaders, move them left and right using their positions. The render for them would look something like this:


void invader::render()
{
glTranslatef(-x,-y,-z);
//render sprite
renderSprite();
}

Hope that helps




PARTNERS