Jump to content
  • Advertisement

iedoc

GDNet+ Pro
  • Content count

    646
  • Joined

  • Last visited

Community Reputation

2554 Excellent

1 Follower

About iedoc

  • Rank
    Advanced Member

Personal Information

Social

  • Twitter
    asdf
  • Github
    asdf
  • Twitch
    asdf
  • Steam
    asdf

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. hit proxy rendering (i think thats what its called) works well, but there's also the stream output stage which you can pipe back out geometry that was created in the pipeline if your using directx, not sure how to do it for opengl though. Ok, sorry, i just realized you said webgl. in that case i would go with the hit proxy rendering, i don't believe there's any other way in webgl, since all you have is the vertex and pixel shaders to work with. webgl2, based on opengl es 3.0, has the added geometry shader, but still don't think you'll be able to pipe geometry back out unless you render it to an image, which in that case you might as well just use the hit proxy rendering (render to depth buffer, then store/render object id to color buffer maybe, or if you can fit the pickable object id in the stencil buffer). if you could fit it in the stencil buffer, or render the id to a separate render target, you could do this in the same pass as your regular draw calls, but that would mean modifying all of your fragment shaders to do that, so it might be easier to just do it in a second pass
  2. What were your findings using a graphics debugger? did you see your draw calls being executed? was the pipeline state exactly what you expected it to be? did your geometry get uploaded to the gpu and used for your draw calls? were your object/view/projection matrices what you set them to? did you get output from your vertex and fragment shaders? did you try stepping through the vertex and pixel shaders? (not sure if that last one is always possible depending on the graphics debugger your using) Normally, at a high level, you should be able to see the output from each of the shaders. this will at least give you an idea of where the problem might be. for example, you see that your geometry was sent out of the vertex shader, but your pixel shader had no output. so you know it was somehting after your vertex shader. or maybe your vertex shader didn't send out your model, so you know it could either be wrong matrices, or your geometry was never uploaded, or it was never bound to be used
  3. use a graphics debugger, like nvidia nsight or visual studios graphics debugger (if your using directx). make sure your draw calls are being made, and the pipeline state is what you expect, and all your data has been pushed up and is available I just realized you said you were using java and opengl, i missed that, so you won't be using the vs graphics debugger, but there is still nvidia nsight and renderdoc
  4. Have you tried using the visual studio graphics debugger? I'm not sure why its slower when you zoom in, but it does make sense that the draw calls are slower because everything you tell the gpu to do before you call draw, gets put into a command list, then actually only executed once you call draw, and the cpu is waiting for the draw call to finish before it continues executing. This might be obvious, but do you have a scissor rect specified?
  5. iedoc

    Weird Error Loading Texture

    where are you uploading the texture to the gpu?
  6. iedoc

    Convert coordinate to zero Z ( 2D )

    are you just trying to project a 3d vector onto the x-y plane?
  7. iedoc

    GameDev Townhall: Steam Opens Up

    I liked their greenlight program before because that way any controversial games that come through, valve would be able to just say "the people wanted it". It was just kind of an extra filter that could have somewhat protected them from backlash because their opinion wasn't the sole filter. Now any controversial games that steam allows are kind of solely on them, and opens them up for direct criticism As for my actual opinion on all of this, i'm actually with steam because if someone doesn't like something, they don't have to look or support it. everyone has their own ideas on what is "bad" or "distasteful" is, and i appreciate steam not trying to make these decisions for me, but instead giving me tools to avoid the things i decide for myself that i don't want to see or support.
  8. Keep a list of all connected clients which you populate as clients connect. If you need to download it from the server , one popular format is json
  9. I'll look at this in more detail later, but in the meantime, two things: first, you shouldn't use d3d10 since d3d11 runs on the same hardware and is meant to replace d3d10 The other thing, is use the graphics debugger to debug your graphics pipeline, it'll save you tons of time. In visual studio, under the debug menu, there's an option for graphics debugger. Click that then click start graphics debugger. Once the debugger is started, press the print screen button to capture a frame for debugging. Once the frame has been captured, double click on that captured frame to see all draw calls and pipeline state for that frame, as well as being able to debug the shaders and see the output from each shader
  10. iedoc

    D3D11 Picking Problem

    what shows (-70, 0, -70)? the ray origin? or the ray direction? If neither, make sure your getting a ray you would expect to get before anything else. is the ray origin the position of the camera correct? is the ray direction somewhat in the direction your camera is facing?
  11. iedoc

    D3D11 Picking Problem

    was this a typo? (using an "m" matrix, i don't see it anywhere else in that code, i'm sure you meant "mat") float3 ray_origin; ray_origin.x = m._41; ray_origin.y = m._42; ray_origin.z = m._43; Also it's not weird that ray_dir.z would be negative the further down on the screen you click, if your camera is facing down. ray_dir and ray_origin should be in world coordinates, so the direction that ray points depends on the direction your camera is facing (as well as where on the screen you click)
  12. iedoc

    Smart glasses with Windows OS

    i'm not aware of any smart glasses that are not bulky, other than the google glass, definitely won't work for what you need, they are more of a heads up display rather than augmented reality. What smart glasses have you been looking at? I don't think the smart glasses technology is quite where you're hoping them to be yet. there's really not a whole lot of choices at the moment. The solution i'd choose is VR, maybe oculus or vive, but again, bulky (and need to be connected to the computer, so probably also not going to work for you). Smart glasses also have a hard time showing black. hololense for example does not show black. black is transparent (The Vuzix looks pretty cool though, i don't think they said what OS it's running on, but it's likely not windows)
  13. iedoc

    Framebuffer

    are you using that framebuffer as a texture? or do you mean framebuffer as in render target? You should only draw when you need to. for example, if nothing changes in your scene, there's no need to redraw everything. use dirty flags or something to know when something has changed Without knowing more about your application, i can only say drawing to your framebuffer every 5-10 frames is fine if you don't need to draw to it every frame Also, make sure your profiling, sometimes the bottleneck is not where you think it is
  14. Get a graphics debugger like Nsight or RenderDoc. This way you can see what information you ACTUALLY sent up to the gpu and are using, as well as you may be able to debug the shaders Also be sure to start simple. try first rendering a triangle in screen space. once you get that triangle rendering, use the world (object), view, and projection matrices. A couple things it could possibly be: Object rendered behind camera or between camera and near plane of the projection matrix (or beyond the far plane, or of course out of the view frustum (out of sight)) Not clearing depth buffer Not sending the position (or other attribute like color) data up to a buffer Not binding the buffer (vbo) before sending the data or drawing the object (not sure if you'd get an error or not), or the vao Not drawing enough indices (if your using indices), or vertices Backface culling is opposite of the winding order your currently drawing the object as Drawing wrong topology (eg. point, line or triangle) Anyway, maybe one of those will get you looking in the right place
  15. iedoc

    Any DX12 books recommanded?

    Have you checked out these? Braynzar Soft DX12 Tutorials
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!