Jump to content
  • Advertisement

paulc

Member
  • Content Count

    101
  • Joined

  • Last visited

Community Reputation

132 Neutral

About paulc

  • Rank
    Member
  1. In opengl/glsl you can compile your shader program with just a fragment shader and let the fixed function pipeline handle the vertex side.
  2. paulc

    pixel shader compile error

    double doh. Your right, the only thing a pixel shader should return is the final colour of the pixel. Wasn't looking closely enough.
  3. paulc

    pixel shader compile error

    While this probably isn't it, could it be that you have used 'tex' in both structures? It really shouldn't cause a problem, but the error message suggests that it is a problem with 'tex', so it might be worth changing one of the instances to see if it fixes it. Edit: doh - beaten to it, sort of...
  4. paulc

    shadow maps- w/o pixel shaders?

    There's a good demo and explanation here: http://www.paulsprojects.net/tutorials/smt/smt.html Its relatively old, so doesn't include use of the frame buffer object extension, which makes shadow mapping easier, i.e. you can drop pbuffers out of the equation, but is still a very good starting point. There is also a demo in the Nvidia SDK, think it also lives somewhere on the developer website as well.
  5. I have a slightly different scene graph structure, using more generic wrapper nodes and hand-rolled rtti information to determine types. All my individual systems are accessed through static functions on a 'system' class, i.e. I can get the camera manager anywhere in code and access the current player/view camera (or any other camera). On the lighting side, during traversal of my scene I accumulate all visible lights and objects (and also any lights/objects that are not directly visible but may still have an impact on the view; lights that shine on visible objects, objects outside the view but which cast shadows into the view), then in a separate section of code determine interactions between the different types of elements, i.e. which lights each object is lit by etc. So at render time, the mesh data is passed to the renderer and this data also holds a list of lights that need to be used to light the mesh.
  6. paulc

    materials: where to find 'em

    If you're looking for a good source of information on materials you'll find this book more than useful: Advanced Lighting and Materials with Shaders ( http://www.gamedev.net/columns/books/bookdetails.asp?productid=481 ). It describes how to implement a variety of different material types and gives you a good grounding in the theory of light, lighting and materials and how they reflect light.
  7. Neither of the file formats are ideal for parsing yourself, the binary version particularly. As Kalidor said, the files are simply a series of mel commands used to reconstruct the scene from the saved data. If you want to be able to load data your going to be better off either writing a plugin for maya to export the data you want or writing your own program that uses the maya headers and libraries. Using the maya libraries allows you to load the maya file into your own program and extract the data you want. Takes a bit of work, as the maya api is not straight forward, but it can be done. Here are a few links you should find very helpful: http://www.robthebloke.org/ http://www.robthebloke.org/research/index.htm <- particularly good http://florian.loitsch.com/gpExport/ http://www.gamedev.net/reference/articles/article1906.asp http://www.ewertb.com/maya/api/
  8. It uses all 3 different shading languages in variuous places, and has frameworks for all of them (HLSL, Cg and GLSL) on the disk. The most important things is that the book teaches the techniques and theory well enough so that it doesn't matter which language you use, it should be easy to implement it in any of them. The chaper list is: 1) The Physics of Light 2) Modeling Real-World Lights 3) Raytracing and Related Techniques 4) Objects and Materials (how different surfaces reflect light, purely descriptive of the appearance of objects by the way the reflect/absorb/transmit light). 5) Lighting and Reflectance Models (including BRDFs and variations) 6) Implementing Lights in Shaders 7) Implementing BRDFs in Shaders 8) Spherical Harmonic Lighting 9) Spherical Harmonics in DirectX 10) Toward Real-Time Radiosity Appendix A) Building the Source Code Appendix B) Sample Raytracer Implementation Appendix C) The Lighting and Shading Frameworks
  9. I've got it and read probably about 2/5 (and haven't got round to getting back to it yet.) My impression so far was very good, although opinions can vary, YMMV, etc. It starts off with a grounding in light theory, goes over the terminology and physics aspects. It also recommends some further reading that includes material by Richard Feynman which gives a ever so slightly higher opinion of the book. Just slightly though :) . Probably best I stop here, and continue once I've had another look at the book as its been a while since I lasted picked it up, but I definitely found the content to be interesting. It takes you through the implementation of different types of lights, and then continues with material details including BRDF and variations. Which I think was about as far as I got. Its only recently I've had time to get shaders up and running in my framework so I haven't had the impetus to go back and read the rest of the book yet, but I will definitely do so as its the only book I've found so far that seemed to cover this topic in detail and with relevant examples.
  10. It looks right to me. You effectively have two identical lights at the same position lighting the same scene, so the second light will make the scene look twice as bright as having just one light. The shadows will stay the same, but the illuminated surfaces will be brighter. Addendum: From SimmerD's first post: Each light is basically light[ n ] = shadow_term[n] * ( diffuse[n] * tex + specular[n] * gloss ). So the total equation becomes fog( blending + ( ambient + lights[ 0..n ] ) ); which states that lights are additive, i.e. their effect accumulates. [Edited by - paulc on March 1, 2005 8:18:23 AM]
  11. I've got this working before, but don't have access to my source code at the moment and it was a while ago. So, based on that my suggestion would be, in the first version with the message pump are you calling SwapBuffers( hDC ) after your opengl code?
  12. You need an active opengl context before you try and do anything gl related, i.e. telling Devil to use the opengl renderer or loading textures directly into an opengl texture object. You could load the textures into Devil then create the textures later, but the code you have should work if you move it to after the glut setup code and before the glutMainLoop line.
  13. If it will only work point to volume then you could reduce it to such a test by performing the Minkowski sum of the two volumes: http://www.cut-the-knot.org/Curriculum/Geometry/PolyAddition.shtml leaving you with a compound volume or polygon and a point which would simplify the tests needed. You could possbily use shadow volume techniques (i.e. edge extrusion to form a volume) to test occlusion (disclaimer: melting pot type thinking - haven't sat down and considered the implications and problems yet).
  14. I think the problem is caused by the fact that the normal map is effectively the 1st derivative of the height map. The normal map is effectively the curvature of the surface, i.e. the first derivative of the height map. While the height maps may be seamless this does not imply that the normal map will be, the effective curvature at the seams between the height maps may not be continuous. \______ The two lines above meet at a point, but their curvature does not match. If I remember the terminology correctly, they have C0 continuity, but not C1 or above. My tip would be to read up on spline/bezier curves and surfaces, particularly focusing on articles that discuss joining curves and surfaces to form seamless wholes. You should come across the concepts I mentioned here and they will probably be explained much better. (edit: ascii art getting chopped :( Did there used to be a preview button? Or am I imagining things....)
  15. paulc

    Texture splatting question(s)

    While I haven't looked into the technical details, I think UnrealEd terrain texturing may work in a similar way. When you add a texture layer to the terrain you then have to paint where you want the texture to show, allowing you to blend it into existing layers. Very good for coping with steep slopes and cliffs, even though its just a height field, you can paint an appropriate texture over the cliff area and you don't get the horrible texture stretching if you just try and apply a texture over the entire height field.
  • 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!