Hi Christian, Thanks for new examples. I am currently preparing for a week away so too busy to merge them right away, on my return I'll get to them.
Cheers, Robert. On 11 March 2016 at 15:56, Christian Buchner <[email protected]> wrote: > > I fixed the bump mapping effect! > > I didn't think it would be so easy. I added a node visitor that traverses > all Drawables in the scene and runs an osgUtil::TangentSpaceGenerator on > them. The tangent vectors are added as texture coordinate array bound to > texture unit #1. The bump mapping effect is now much improved. > > The remaining concern I have with the proposed sample is the hardcoded > size of the G buffers to 1024x1024 pixel texture rectangle, regardless of > output window size. > > I'll wait for some feedback and discussion before providing any further > updates. Thanks for checking my submission. > > Christian > > > > 2016-03-11 16:30 GMT+01:00 Christian Buchner <[email protected]> > : > >> >> A very minor correction to the Simple room model. I had made a typo when >> I downscaled the texture coordinates manually by factor 10. So on one side >> wall the texture would be slightly distorted. This small update (see >> attachment) fixes it. >> >> At this point I am a bit puzzled by the shader "pass2.vert". It accesses >> gl_MultiTexCoord1.xyz to get a tangent vector for each vertex (has to be >> stored in object space, apparently). >> >> However in the entire code submission it appears no piece of code would >> be setting up any texture coordinate array bound on texture unit #1 (the >> code is not using osgUtil::TangentSpaceGenerator either). So in my opinion >> the t_worldspace and b_worldspace vectors will always be 0, which is why >> the bump mapping effect only scales the z coordinate of the normal vector >> in this expression in "pass2.frag". So >> >> vec4(nn.x * t_worldspace + nn.y * b_worldspace + nn.z * n_worldspace, >> 1.0); >> >> effectively becomes >> >> vec4(nn.z * n_worldspace, 1.0); >> >> Due to lack of tangent vectors, we get a somewhat incorrect bump mapping >> effect. It does not look quite as good as it should. >> >> Christian >> >> >> >> 2016-03-11 15:04 GMT+01:00 Christian Buchner <[email protected] >> >: >> >>> Apologies, I should have attached the actual code submission. I am doing >>> this now with my reply. >>> This submission is zipped to take minimal space. >>> >>> Christian >>> >>> >>> 2016-03-11 15:03 GMT+01:00 Christian Buchner < >>> [email protected]>: >>> >>>> Hi all, >>>> >>>> I am hereby submitting a deferred rendering code sample, originally >>>> written by Michael Kapelko in 2013. I am submitting this code with his >>>> approval. >>>> >>>> Deferred rendering is now the de-facto standard rendering technique in >>>> many modern game engines, hence I think it is important to have this >>>> technique demonstrated in an osg code example. >>>> >>>> This particular sample adds soft shadows as well as bump mapping into >>>> the rendering pipeline. The image files whitemetal_diffuse.jpg and >>>> whitemetal_normal.jpg from OpenSceneGraph-Data images folder are required >>>> (The OSG_FILE_PATH environment variable must be set correctly) >>>> >>>> Two additional osgt models are included with the demo (best to also put >>>> them into OpenSceneGraph-Data, I think. >>>> >>>> The shaders are currently defined in separate .frag and .vert files. >>>> Should we put these directly into the source code instead? >>>> >>>> Christian Buchner >>>> >>>> >>> >> > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
