Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Mar 2012
Offline Last Active Nov 06 2015 08:51 AM

Topics I've Started

How to tell if a function parameter is an object?

30 April 2014 - 11:12 AM

Hello all,


First, let me describe the behavior I am trying to implement.  I have created a custom wrapper around Angelscript functions in order to make calling them easier.  One of my wrapper functions handles the "pointer" case (i.e. the user passes a pointer as a parameter).  In this situation, Angelscript can either accept this parameter using SetArgObject or SetArgAddress.  What I would like to do is try SetArgObject first, and if that fails, then try SetArgAddress.  However, the problem I am facing is that if I pass an invalid parameter to the context, it invalidates the entire context, and prepare must be called again in order to use the context again. 


I did some digging into the Angelscript code and noticed that before the context actually sets the argument in SetArgObject, it first checks the function to see that the parameter is an object, and if it's not, it returns and error and sets the error code.  It would have been nice, however, to know before calling SetArgObject that the call would be rejected, so that I didn't have to invalidate the context.  The problem is it seems the data types used by Angelscript to check if the parameter is an object are hidden from the front-facing API.


What I would ideally like is to do the same check that the context does before setting the object to make sure I am passing in a valid object to the context to avoid destroying the current context state.  Does anyone know any way to do this, other than modifying Angelscript?  


I hope this hasn't been too hard to follow.


P.S. For Andreas: one solution I have come up with is to expose the asCDataType as asIDataType and allow users to query the data types for function parameters in the public asIScriptFunction interface.  I would create a new method on asIScriptFunction, like GetDataTypeForVar(int index) which would return an asIDataType.  If you are happy with this solution, I can implement it and send you a patch for your approval.  

Texture Swapping: Does size matter?

05 March 2014 - 09:40 PM

Hey all, 


I am wondering something about texture swapping, hoping someone can shed some light.  Question is simple:  If I swap to a different texture unit, whether it be DirectX or OpenGL, will the operation take longer depending on the size of a texture?  In other words, is a texture swap to a 64x64 texture the same cost as a 2048x2048 texture?  Is it just like changing a pointer, or does it actually have to move the memory to make it accessible to the GPU?  It is safe to assume in this situation the textures are fully initialized and have already been rendered with already (so the data is guarenteed to be in GPU memory), and that the data will not change for the runtime of the application.


It seems intuitive to me that it would take longer for the larger texture swap, but I have found more than once that the GPU does things that surprise me, so any knowledge here would be great.  Thank you.

Question about Irradiance Environment Maps

20 June 2013 - 08:01 PM

Hello All,


I've been reading about using spherical harmonics to create irradiance environment maps and I want to give it a shot.  However, one question I have, which I can't seem to find an answer from in the resources I'm reading is how the original cube map is formed.  So obviously in a static scene, you can just load a cube cross from disk, and viola.  But, for real time rendering, you are going to need to regenerate this environment map on every single frame, theoretically.  So the way I see it, this is my rendering batches:


  1. Render the current environment 6 times, one for each cube face, render to a texture
  2. Compute my irradiance environment cubemap, send it to the video card
  3. Render the environment again, this time from the POV of the camera
  4. Render all of my objects with my irradiance map

Now maybe I'm underestimating my GPU, but this seems like a lot of processing.  It seems nearly impossible that I'm going to be able to do all of this in 16ms and still have time to spare to update the rest of my game world.  Is there something I'm missing here, or is this generally the strategy used for real time irradiance environment maps?

Scene Graph with multiple cameras per frame

07 June 2013 - 05:05 PM

Hello all,


I am designing a scene graph for my rendering engine.  I would like to use the same rendering engine for rendering my GUI and my game objects, however, this means that I would need to switch cameras during rendering.  Here are the options as I see them:


Option 1: Create a separate scene graph for each type of camera.  

Option 2: Use the camera nodes as the root nodes, and add other top level nodes as children of the camera nodes.

Option 3: Something I didnt think of?



Constant Buffer By Name in HLSL

05 June 2013 - 05:00 PM

Hello all,

I am currently in the process of creating a rendering system that will work with both OpenGL and DirectX. One of the things I would ideally like to do is flatten out the differences between shader programs, since they fundamentally work the same way. I have created an IShaderProgram interface which is the accessible type, and then implementations for OpenGL and DirectX, which are hidden.

Everything I have created so far hasn't required me to compromise anything in terms of architecture, but there is 1 last hitch: HLSL doesn't allow you to retrieve constant buffer locations by name, and OpenGL doesn't let you bind uniform locations to a specific index. The result is that I would have to either create a method that allows you to "bind" your "global data" locations, where you provide a name, index, and shader type to the IShaderProgram interface, and OpenGL would simply ignore the index, and grab the location from the shader. I don't think this is the worst thing in the world, but it's a little bit dirty. I was wondering if anyone knows of a way around this, possibly getting constant buffer's by name. One thing I considered is parsing the HLSL source code. Another is using the D3DXEffect framework, but I would like to avoid this. Just wondering if anyone has any thoughts on this matter, or possible ways to fix this little issue.