shadow_receiver_vertex_program_ref not exists in oFusion!?

Hi
shadow_receiver_vertex_program_ref not exists in oFusion material!
i don't know why, but oFusion Pass only have vertex_program_ref and fragment_program_ref.
here is a part of ogre advance-material file, how can i do that with oFusion?

shadow_receiver_vertex_program_ref Examples/BumpMapVPShadowRcv

{

param_named_auto lightPosition light_position_object_space 0

param_named_auto worldViewProj worldviewproj_matrix

param_named_auto worldMatrix world_matrix

param_named_auto texViewProj texture_viewproj_matrix

}

// Additive texture shadow receiver program

shadow_receiver_fragment_program_ref Examples/BumpMapFPShadowRcv

{

param_named_auto lightDiffuse light_diffuse_colour 0

}


Thanks for any help.

Hi mr Ahmadi,
i'm do not know.
please go to your home.
thanks very very mutch.

This is something I would really like to know how to do as we move away from fixed function and towards heavier shader usage!

I'm wondering how we move away from fixed function and handle shader based texture shadows in tools like ofusion too. Lioric said there would be a new version of ofusion on the 27th Nov. Almost a week ago now.

I wonder if that was going go be Ofusion 2.0 with new features? Ofusion 1.9 was mostly the same as 1.8 but for ogre 1.4 and had ofusion support.

Anxious to see a ogre 1.6 build of ofusion since were getting ready to migrate to it in our app. Hoping the next ofusion has some way to support shader shadow types.

... Lioric said there would be a new version of ofusion on the 27th Nov. Almost a week ago now...

Do you know new features of it?

... Lioric said there would be a new version of ofusion on the 27th Nov. Almost a week ago now...

Do you know new features of it?

I wish I did, there have been snippets of information here and there from Lioric over the past year regarding Ofusion 2. But most of that is probably speculation. There was mention of particle support at one time. Whether that means simply loading a particle script, or creating one from scratch in 3dsmax, I don't know.

We will just have to wait and see. Right now I'm mostly interested in getting a version of ofusion that works with shoggoth with scene loader and serializer. (incase the OSM format changed)

Were thinking of releasing a beta of our game framework and OSM Editor for christmas, and hoped to be up to date with a shoggoth version from the start but might have to stick with Dagon till next year since time is short.

Yes, this has been added previously (some of the first features that were implemented for the new version) and will be relased with version 2

I thought I might add some info to this. I've recently implemented a new production pipeline for our studio which now relies heavily on shaders instead of fixed function. The core feature of this is Depth Shadow mapping.

For some time I was under the impression I needed to use things like shadow_receiver_vertex_program_ref, shadow_receiver_fragment_program_ref and shadow_caster_vertex_program_ref. In the end this wasn't the direction I needed to go, I couldn't get this to work.

My solution in the end was the line.

shadow_caster_material

This sits within the Technique of a material, and points to a completely seperate material for shadow casting. A much better approach than things like shadow_receiver_vertex_program_ref. This way you can totally customise your casting material, using different texture units to your receiving material, etc.

The ONLY thing letting my workflow down is two things

-the ability to set shadow_caster_material
-the ability to flag a texture unit as content_type shadow.

This is really, really having huge issues on our workflow. I've been trying to get this stuff implemented for a couple of months. IMHO all it needs is a tickbox/dropdown box in a texture unit to set the content_type, and a textbox in a technique to set shadow_caster_material, essentially exactly the same way as we enter in a user defined scheme name. I have no care if it does not affect the viewport, as I doubt my shaders are going to work with the viewport anyway without some ogre code changes.

Currently I have to put my shadow_caster_material name inside User Defined Scheme, and do a find/replace in the exported material file. I also have to link my texture unit up to a specific TGA, and do a find/replace for that name and change to content_type shadow. It's a terrible workflow at the moment. 7 licenses in the studio exporting a dozen or more times a day, means a lot of find replacing and huge room for error. Even with some sort of post processing app that does this automatically, its less than ideal.

Does anyone else need these features to move towards shader based outputs??? Please let me know as I'd really like to see these implemented sooner or later.

I completely agree with Major here.

I'm currently facing the task of combining a shadow shader with our other shaders and how oFusion is right now it's pretty much impossible to do. Our artists want WYSIWYG and without the ability to integrate the shadow shader into our materials it is just a dream. The ability to define content_type shadow is essential and also the ability to set shadow type to additive integrated. Also with a couple more lines you could effectively use PSSM shadows which are already built into Shoggoth.

Ogre is advancing and the days of fixed pipeline are over but oFusion is still using old shadows which really kills the workflow. This really needs to be addressed.

There are definately a few weak points in Ofusion these days. I use Ofusion pro when I can but lately I've been doing more and more contract work with developers using .scene and since Ofusion Pro doesn't support it and programmers are reluctant to support OSM when they have media coming from other apps too I've had no choice but to use Ogremax for quite a lot of my paid work and Ofusion for personal work.

Ogremax has a few advantages over Ofusion Pro is some areas these days, one being the support for the more recent shadow types, and the other being particle support. Both of these things were mentioned as being implemented in ofusion months ago, Shader FX 3 feature support was due 4 months ago.

Would definately be nice to see some Ofusion Pro progress in these areas, Currently Ofusion Pro is still ahead of ogremax but really needs a few key areas to be addressed. CE is lagging way behind either which is unfortunate.

Yep, oFusion is still the way to go IMHO but it's just highly annnoying that we're still lacking these features which essentially breaks the WYSIWYG experience. Adding the new shadow features to oFusion should be a fairly easy task.

Currently if I added shadow map handling to my shaders, they would not compile because of compile errors since the shadow textureunits don't exist.

I noticed Ofusion PRO is currently at 1.9.7 so hopefully v2.0 with all the new features Lioric has mentioned over the past year isn't too far away .

A new hotfix for pro has added the ability to specify Shadow_Caster_material, Shadow_Receiver_material, and make a texture unit a Content_type SHADOW.

I'd consider this issue solved as a result.