Jump to content

  • Log In with Google      Sign In   
  • Create Account

Nanoha

Member Since 26 Feb 2009
Offline Last Active Today, 02:33 PM

#5312467 Problem with Diffuse Lighting

Posted by on 25 September 2016 - 04:15 AM

@AliasBinman, I don't understand what you mean, can you explain this with some code?

 

In your shader you have:

cbuffer cbPerObject
{
    float4x4 WVP;
    float4x4 World;
};

In your code you set the value of WVP but you never set the value of World so it is likely to be using a matrix full of 0s. You then multiply your normal by that:

output.normal = mul(normal, World);

which will leave your normal being (0, 0, 0) which is invalid. Dot product with that will also be 0 and so your diffuse contribution also becomes 0.

 

Well spotted Aliasbinman,




#5312321 Problem with Diffuse Lighting

Posted by on 24 September 2016 - 09:59 AM

I don't know what the problem is but these values look a little odd, are they correct?
 

    light.dir = XMFLOAT3(0.25f, 1.0f, 1.0f);
    light.ambient = XMFLOAT4(0.2f, 0.2f, 0.2f, 1.0f);
    light.diffuse = XMFLOAT4(1.0f, 1.0f, 2.0f, 5.0f);

I would expect light.dir to be normalized and diffuse to have only values <= 1. This may not be true for what you are doing though (I didn't check the tutorial you are following). I would suggest cutting this down a little to it's bare-bones and trying to identify what's wrong from there. Looking at your vertices it is difficult to work out what elements are what but from your shader I guess it goes position/tex/normal; in which case your normals look very odd, even if they are position/normal/tex they still look odd. I would start with that.

 

If all that is correct then you could try commenting out your current fragment code and put in some very basic code instead. I would do just

float d = dot(light.dir, input.normal);
return float4(d, d, d, 1.0);

That should at least show if the normals/light dir are correct, it'll be white for surfaces directly facing the light and fade to black as faces are turned away. d will be -1 for faces looking away but that should still come out as black. Once you have confirmed those are correct you can then add in the part for material and light color again and then add ambient back in.




#5311599 Inserting element into vector during iteration causes crash

Posted by on 20 September 2016 - 05:25 AM

Your code is a test, you won't often find this situation as much in real code but it does happen. In general just avoid changing the vector while iterating. Store up the things you need to add while iterating (but don't add them) and then after you finish the loop add them all on (as others have suggested). 

 

When removing elements while iterating you have a way to deal with iterators changing so that's not as much of a problem.

 

This has a little section at the bottom that explains a few things:

http://www.cplusplus.com/reference/vector/vector/push_back/

Generally about what becomes invalid and when.




#5311591 Find angle to get from point A to B with x amount of bounces

Posted by on 20 September 2016 - 04:57 AM

What a great problem to have. This solution is also along the lines of what Lactose suggests. See the attached image.

 

Very little maths involved with this, all you do is get those extra end points off the sides, you can see that every other the end point is mirrored (as Lactose says, flipping odd an even bounces). Once you have those points you just aim at them instead. If you want no bounces then aim directly, if you want one then aim at the second point, want 5? Aim at the 6th point and so on. It will also work firing in the opposite direction.

 

 

One potential problem is that in my image these are points but with a circle it will behave differently.

Attached Thumbnails

  • IMG_20160920_115004.jpg



#5311311 I want to learn untiy engine but its too difficulrt

Posted by on 18 September 2016 - 12:32 PM

Why can you not speak very well? Language barriers?

 

I'd recommend learning some basic programming first in a language (spoken) that you understand. Perhaps something like Python, should be able to find some tutorials/resources in whatever your native language is. c# is a fairly popular language so you might be able to find some tutorials in your language for that (depending what your native language is). 

 

It is difficult to learn programming, c#, game programming and Unity all at once. You should try to learn some basic programming first without all the other factors and then slowly pick those up too. I suggested Python because it is a little easier to learn than c# while still having all the basics you will require but eventually you would want c# for Unity (or Java) so you could skip the Python step and try some beginner c# tutorials (without Unity).

 

Visual Studio Community 2015 is free and will let you code in c# without needing any Unity so consider trying that. If you mention what your native language is perhaps people can offer tutorials in your language. I don't really know of any c# tutorials myself.




#5310787 Buying a pc for game development courses in college.

Posted by on 14 September 2016 - 12:05 PM

I'd avoid buying something based on name (Alienware) but I genuinely have no idea if Alienware is good or bad. At one point they were considered good but  after being purchased by Dell they were considered bad but things don't just change as simple as that so it's all opinion rather than facts but it works both ways, just because a name is popular doesn't mean it is a good choice.
 
I have always put together my own computers but I know people who have just bought prebuilt systems and they are equally happy. Putting together your own computer isn't that difficult any more, there's far less than could go wrong and in a way it is quite satisfying. I'm not sure if it works out cheaper or not (to assemble your own) as these larger companies do tend to have a lot of buying power but as a potential cost saving it is worth finding out.
 
I am a reasonable gamer so my choice has always been based on that more than development. Are you more geared towards development? You can probably get away with a slightly cheaper system if that is the case. As a student you might also want to consider a laptop, with the new 10 series from Nvidia you can get some serious gaming power in them now.
 

should i buy a very exepsnive pc , and just not have to worry about anything for a really long time?

 

I'd avoid buying a 'very expensive pc' just because the more it cost the less value for money you get. Get something quite top end but not too top end and it can easily last you 3 years. One of the good points of making your own is you can pick expensive parts where it matters and cheap out in other places (although these prebuilt systems do give you a fair few options now).




#5310248 Vector and matrix multiplication order in DirectX and OpenGL

Posted by on 10 September 2016 - 08:27 AM

Yeah this is defiantly hell.
 

 

I gotta agree on that one. I find the best method of dealing with this is to start at the end and work back. I think of my vectors as a vertical column so mathematically they then have to be the second argument of a multiplication (with a 4x4 matrix) or else it can't be multiplied. Once that's set I then I know that I have to build my transforms a certain way (e.g. the translation needs to be in the last column).

 

Then you need to hide everything away behind functions and avoid creating a matrix directly from values. That way you never really care what ordering it is, it'll just work as you expect it to. The only confusion then comes when you send it to your shader but you can document that step in your code quite thoroughly so once you have it once it shouldn't be an issue. You might need to transpose before sending but that's about it.

 

I believe the mathematical convention is actually to go down columns first and then across rows (which is the opposite of most other things in maths as you tend to go across first then up) so things being column major does make sense in that regard.

 

This has probably been the topic that causes me the most confusion too. Thinking backwards, trying to stick with mathematical convention and using functions/abstraction helps a lot.




#5310219 Vector and matrix multiplication order in DirectX and OpenGL

Posted by on 10 September 2016 - 03:19 AM

 

You are doing an uncorrect syntax of mat4 constructor and there is no need to specify the f of floats in GLSL, it should be 

mat4 buffer_modelMatrix = mat4(1, 0, 0, 0.5,
                               0, 1, 0, 0,
                               0, 0, 1, 0,
                               0, 0, 0, 1);

Off the top of my head that might not work either. I recall GLSL being really picky when you start mixing integers with decimals. You might have to put .0 on the end of all the numbers not just the.

 

As for what is actually going on I cannot say for sure but I don't think you can actually change whether a matrix is row or column major in either of those since that is a matter of how it is laid out in memory which is out of your hands at that point. What you can change is the matrix you build to account for that. you are transposing those matrices which is effectively accounts for that. As far as I can tell, when you swap the order of multiplication you are transposing the (in) position vector as there is a mathematical limit to the form of matrces that can be multiplied together. When the vector is on the right it will need to be vertical but when it is on left it needs to be horizontal. I believe both OpenGL and DirectX handle that for you transparently.

 

According to this:

https://www.opengl.org/wiki/Data_Type_(GLSL)#Constructors

For multiple values, matrices are filled in in column-major order

The matrix that is build using Supremecy's code (and I assume what you intended) would make a matrix that is suitable to be multiplied when a vector is horizontal, meaning the vector will need to be on the left. If you want it on the right then you will need to transpose the vector.




#5308514 the dreaded "escort" quest

Posted by on 29 August 2016 - 11:52 AM

I played Guild Wars 2 yesterday (for the first time in years) and one of the things I noticed about the escort quests there than I immediately liked was the NPC does not die completely. It can still go down but people could revive them just like they can revive other players. The only issue with that is the lack of failure so that would be more a design choice.




#5308321 Help with glDrawElementsInstanced

Posted by on 28 August 2016 - 02:38 AM

 

At the bottom of your SetInstancing method you bind the vertex array to 0 but I don't see it being bound initially. From your other method it looks like you are binding m_vao at the start then binding it to 0 at the end of the methods. Have you perhaps just missed binding m_vao on that one particular method?

That fixed it! I'm still trying to wrap my head around OpenGL being STATE-DRIVEN (it doesn't help that I'm mixing object oriented C++ and procedural OpenGL, but I guess that's part of the learning process) rolleyes.gif

 

Thanks so much! biggrin.png

 

 

Yeah little things like this are easy to miss. I sometimes make little objects that ensure a thing is bound and unbind in the destructor similar to how lock guards work and I throw one at the start of my function. 

 

e.g.

TextureBinder(int desired)
{
   m_desired = desired;
   // get currently bound texture and store it
   m_previous = GetCurrentTexture();
   // if it's not the desired texture then bind it
   if(m_desired != m_previous)
      BindTexture(m_desireD);
}

~TextureBinder()
{
   // rebind the previous one if it was different
   if(m_desired != m_previous)
      BindTexture(m_previous);
}

// Then in a method where I am messing with that texture:
void A::DoSomething()
{
   TextureBinder binder(m_texture);
   // modify it
   // it is automatically reset to the previous when the method ends
}

That does add some overhead (resetting the value) but if you are doing it anyway then it's no worse and it does help avoid little mistakes like the one you had there.




#5308284 Help with glDrawElementsInstanced

Posted by on 27 August 2016 - 05:37 PM

At the bottom of your SetInstancing method you bind the vertex array to 0 but I don't see it being bound initially. From your other method it looks like you are binding m_vao at the start then binding it to 0 at the end of the methods. Have you perhaps just missed binding m_vao on that one particular method?




#5307586 Collision Detection error

Posted by on 24 August 2016 - 06:12 AM

Those globals are going to ruin your day. I'm not sure what is causing your exact problem but from looking at your code it is not very good design-wise. I would advice against trying to fix this problem and instead remove all those globals you have, that will then force you to redo how you solve your collision detection/response which should hopefully no longer exhibit the problem you have. It's better to build on a strong foundation now than end up with worse problems later.




#5307041 Modal GUI and ongoing events

Posted by on 21 August 2016 - 11:28 AM

In the past I've deal with this like a 'focus lost' type situation. I'd send an internal event saying the focus was lost (I can't recall the exact wording) and anything that found that useful could listen for it do something with it. The system that is handling whatever the mouse is dragging could listen for the event and deal with it (drop the item for example).




#5306852 Opengl:why glEnableClientState(GL_TEXTURE_COORD_ARRAY); generate error?

Posted by on 20 August 2016 - 02:43 AM

From your other thread that I was posting in it sounds like the version of OpenGL that you are using doesn't support fixed function or default vertex attributes (glTexCoord and so on) so that's probably why this is  generating an error, it no longer exists. The brief search I did suggests that it was removed in 3.2 (maybe 3.1). If this is the case then glTexCoordPointer probably doesn't exist either. I read there is a compatibility mode that you can enable that allows these things to work so the function might still exist. I would suggest you take what you have learned from the other thread (where you were using vertex attributes) and use those for your texture coordinates too.
 
I'm not sure why your second post was down voted as moving your check error function around is a reasonable method for narrowing down and finding which function is generating the error.
 
It will be helpful if you can find out which version of OpenGL you are targeting and add that to your OpenGL questions. It'll allow people to quickly help you with your problem.
 
This is the API reference for OpenGL 4.5 https://www.khronos.org/files/opengl45-quick-reference-card.pdf there are others for previous versions also here


#5306606 Android, OpenGl ES, panning + zooming

Posted by on 18 August 2016 - 01:47 PM

Great to hear you have it working now. 






PARTNERS