SetParameterData usage?

Nov 15, 2012 at 7:36 PM

When I rotate a sphere in a scene I set up with H3,I create its color like in the samples:

m_LightParams = Vector4f( 1.0f, 1.0f, 1.0f, 1.0f );
m_pLightColor = m_pRenderer11->m_pParamMgr->GetVectorParameterRef( std::wstring( L"LightColor" ) );
m_pLightColor->InitializeParameterData( &m_LightParams ); 

But in the Update() loop when I use  m_pLightColor->SetParameterData(...) with a new vector with random generated floats,nothing happens.It only has effect if I use InitializeParameterData() in the update loop,only then does the color change.Is it intended to work like that?

Coordinator
Nov 16, 2012 at 1:02 AM

The reason is that the parameter system is by default set up for multi-threaded processing.  Each parameter has as many slots for a value as there are threads configured in the engine - which by default is 4 (with another value slot available for the main parameter manager interface).  When you call InitializeParameterData, you are setting all of the value slots to the provided value.

If you call SetParameterData, there is a second parameter with a default of 0 that indicates which thread to set the value for.  So most likely your value is being set, but in the 0th slot which may or may not reach your intended target.  This is a slightly difficult topic to explain in one post, but if you check out the word document in the Hieroglyph3/Documentation folder then it may help you out a little.

So to recap, using the InitializeParameterData method is a way to set all of the slot values, which is usually handy for a quick and dirty way to set a parameter when you aren't calling from within rendering process (so calling this in the update loop is valid, but anywhere inside the Scene->Render() call is not).  Lately I have been migrating to always using a ParameterWriter to get the values into the parameter system.  This allows you to 'stick' a parameter to either an entity or a material, and they will be set accordingly in the processing thread within the Scene->Render() call.

You can take a look in VolumeActor.h/.cpp for an example of using a custom parameter writer.  The only issue is that for a light, you are typically not going to have a different light value for each entity or material - it should be at the scene level.  That seems like a good idea - to add the ability to have parameter writers added to the scene as well...  I think I'll add that in for the next code commit.

Sorry if this is a bit rambling - if it is still not clear, please feel free to continue asking until it makes more sense!

Nov 16, 2012 at 5:27 PM

It's ok,I understood it,btw this may be off topic,but are you planning to add material ordering to minimize state changes?It seems that this gets less required as the materials get more complex,since in the end,it turns out every object on the scene has some variation in the material(like modern games).

Coordinator
Nov 17, 2012 at 8:07 PM

That could certainly be done, but it would require the sorting to be done in a render view.  Originally that was the inspiration for creating render views - to have a modular way to try out different ideas for submitting the geometry.  It was later on that I ended up using the idea for implementing different algorithms.  So a customized render view would cache all of the Entity3D instances that would be rendered, then sort them and submit them to the renderer.

So at the moment I don't have any plans to do that, but it would certainly be possible.  Perhaps in a larger scale application it would make sense, but for most demos or sample applications it isn't necessary.