Vramesh AUTOGEN forests 1 Mod

[vramesh]

Greetings Stickman and PV!

Thank you Stickman for illustrating the difference between "shine" and "glow". I was (wrongly) using the two terms interchangeably.

To summarize the choices for trees:

A) Bin version 2 with adjusted normals by Vasanth: glow at dawn, don't at dusk and don't shine at all. May not respond properly to changes in .fx files.
B) Bin Version 2 with Stock trees: Shine like mirrors(because the shaders don't work properly), especially at dawn and dusk. Can be fixed with the .fx file but may require Directx9c SDK/D3Dcompiler_xx.dll install and complete uninstall and re-install of the game with several reboots sprinkled in between to make the .fx file work.
C) Bin Version 1 : Don't shine, don't glow and don't occlude clouds. Considered bad. Especially when viewed from ground level at airfield. Vasanth to try to convert them into bin 2 and see if that fixes the problem.

If you can make the .fx files actually function, where we can play with them,
then we can have some added freedom of movement
and the ability to tinker with, tweak, and other wise calibrate the variables therein.

I can!! You can too!! But, it comes at a cost though....a few (maybe just one, if lucky;) ) frustratingly maddening complete uninstall-reboot-reinstall-check-wash-repeat cycles.

###################################################################
My dialogue with Stickman on with fiddling with .fx file reminds me of Monty Python's Parrot Sketch (adapted). Substitute .fx file for parrot, Stickman for Mr. Praline and me for Owner . All in good jest:

Mr Praline: "I'll tell you what's wrong with it, my lad. 'E's dead, that's what's wrong with it! 'ELLO POLLY!!!!! Testing! Testing! Testing! Testing! This is your nine o'clock alarm call!"
(Takes parrot out of the cage and thumps its head on the counter. Throws it up in the air and watches it plummet to the floor.)
Mr Praline:"Now that's what I call a dead parrot."
Owner: "Well, he's...he's, ah...probably pining for the fjords."
Mr Praline: "PININ' for the FJORDS?!?!?!? E's not pinin'! 'E's passed on! This parrot is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisible!! THIS IS AN EX-PARROT!!"
Owner: "There, he moved!"
Mr. Praline: "No, he didn't, that was you hitting the cage!"
Owner: "I never!!"
Mr. Praline: "Yes, you did!"
Owner: "I never, never did anything..."

To be honest, I also thought that the fx files were dead. Unlike Polly the parrot though, the .fx files in BoB2 are very much alive.
#################################################################
Here is my first tweak -- Make the #1037 trees look reddish:


On a related note :
Hazzie:
*ALL* ground objects, not just trees, (irrespective of whether they are shpbin or grpbin or version 1 or version 2 or normal adjusted or not) will show as "black-dots" through clouds at extremely far distance (when the object is supposed to start being visible but just as a speck). Could be LOD related. Don't know how to solve it ...yet

Regards,
Vasanth

[stickman]

Vasanth,

You had me laughing with the Monty Python lines.
Of course I had to watch it with YouTube, and the parrot was actually... Dead.
Only appeared to look alive to the customer, because it was nailed to the perch.
Just like our BoBII trees.fx file.

https://youtu.be/aqz_4OgMi7M

------------------------------------------------------------------------------------------------------------------

Where did you get the DirctX9c SDK files?
I see this place:
http://directx-sdk.soft32.com/

We need to have these .fx files working for v2.14.

------------------------------------------------------------------------------------------------------------------

In the meantime, for v2.13 players, your new tree .BIN files fix a lot of problems, and all trees are much improved.
Can actually use some trees now, that never worked well before.
The AUTOGEN forests have never looked better.
Thank you.

[vramesh]

Dear Stickman,

Here is the link to the Directx9c SDk that I have installed.

To avoid any potential conflicts and issues that may arise with the (possibly) various flavour/versions of the SDK, I have uploaded the version that worked for me.

Also, I lost the original link !


Steps that I took to make .fx file work:
1) Download SDK
2) Back up BoB2
3) Completely uninstall (used ccleaner too) BoB2
4) Reboot
5) Install SDK
6) Reboot
7) Install BoB2 (no patches yet) and start game once
8 ) Apply 2.12 or 2.13 patch. I've tried with only 2.12.
9) Start patched bob2 again. You should see the .fx file effects now.
10) Restore game settings from back up in step 2.

I don't know which combination of d3dx9 and d3dcompiler dll from the SDk made the .fx files work.
Didn't succeed in forcing an existing BoB2 install to use the newly installed dlls from the SDK. Yet.

###################################################

Just earning good karma by helping plant more trees. Doing my bit to make BoB World "go green(er)"

--
Vasanth

[ShadowShooter]

Hi vramesh

If you're keen on learning to edit and write fx files you might find NVIDIA FX Composer 2.5 [a free (and large) program complete with nice GUI, manual and a shader debugger plug-in] interesting and useful:
https://developer.nvidia.com/fx-composer

It's also a lot of fun to play around with!

[vramesh]

Dear ShadowShooter,

Thank you for the link. I'll try them out this weekend.

Regards,
Vasanth

[vramesh]

Dear Stickman, PV,

To get the .FX file working again in BoB2, an uninstall/reinstall of BoB2 may NOT BE necessary. Here is how I found it out....

Today, I was perplexed to find that the fx files for trees WORKED correctly EVERY TIME after a reinstall and before restoring from backup and BROKE EVERY TIME after I restored stuff from my backup.

I then traced the problem to this line in BDG.txt:
MULTI_SKIN_MODE=DISABLE # valid modes: DISABLE, ENABLE, FX_FILES_ONLY, MS_FILES_ONLY. Only active when MultiSkin is installed

I had tried multi-skins once but, found that my laptop couldn't handle it. Since then I had set this variable to DISABLE and had forgotten about it all together.

Setting it to ENABLE or FX_FILES_ONLY fixed the problem.

I also noticed that upon reinstall, the default value for this variable in BDG.txt is ENABLE, which explains why I was seeing the FX file effects everytime after reinstall.
When I restored the bdg.txt, this value got overwritten to DISABLE and hence could not see the FX file effects.

I had previously written

Didn't succeed in forcing an existing BoB2 install to use the newly installed dlls from the SDK. Yet.

It didn't occur to me to check for this variable. I think if I had set it to ENABLE or FX_FILES_ONLY, I would have seen the FX file effects without a reinstall.
Now it is too late for me. I have already uninstalled and reinstalled and restored from backup.
Anyway, just giving a heads up so you guys may avoid an unnecessary reinstall.

Dear Shadowshooter,
I have downloaded the tool. It is approximatety 180 MB. Going through the tutorial in the website. Looks like a fun tool to learn.

Regards,
Vasanth

[PV]

Wow. OK, another item to fix for v2.14
We obviously don't want the multiskin
setting controlling .fx files for other objects.

[stickman]

Vasanth,

Ah!
No wonder why my trees.fx "parrot" was dead!
I also had my MultiSkin DISABLED.
Get faster loading times when jumping into and out of the game, with MS DISABLED,
when messing around with different trees, or fiddling with MAINWLD or introducing or modifying GROUP.BIN files.
As an old man, I have less patience now, wasting time, than when I was younger.

PV is right. The .fx files should work ALL of the time.
No matter what bdg text switches are turned OFF or ON.

[vramesh]

Dear Stickman and PV,

Several posts ago, I had written:

#62 tree1, #1192 beech and #1543 frst are all version 1 BoB2 objects (meaning they are made of BoB2 draw primitives) and that may have something to do with how they work with clouds.
I can try to translate them to version 2 bins and see if this problem goes away.

Well, this weekend I was able to squeeze out some time for BoB2.
I was able to get a better understanding on how LODs are stored in the new Version 2 bin. I also was able to translate a BoB2 version 1 bin to a BoB2 version 2 bin and here are the results:

So then, improper cloud occlusion is indeed a BoB2 version 1 object problem. I notice this with phare.bin, guet.bin and gavet.bin which are BoB2 version 1 bins too.
On the left is the new version 2 bin of #62 oak which occludes clouds well. On the right is the stock BoB2 version1 #62 oak.
There is only one LOD in the new bin file. But that is all that is needed. Should work well with Autogen (at least as good as the old #62). They are also' normal adjusted' to avoid the dawn/dusk "shine".
One catch is that, pcx files no longer work in version 2. DDS files are okay.

Here is the new tree1.bin translated into version 2 format:
https://www.mediafire.com/?tc7yg6wdc3iou99
You may need to
1) copy TREE1.bin to your shpbin folder and
2) copy tr.dds and sh.dds to COCKPM16 folder.

The dds textures may require some 'professional' touch. As usual, I included the dds for proof of concept. Please let me know if they don't work properly or cause any unwanted issues.
If it looks okay, then I shall proceed doing the same to 1192 beech and #1543 frst (and phare and guet and.... ).

Regards,
Vasanth

[PV]

There are of course two problems with objects and clouds:
in one case, the clouds appear inappropriately in front of
the objects, in the other case, the objects appear inappropriately
in front of the clouds. What I wonder is, if you repair the
one behaviour, do you repair the other, induce the other,
or have no effect on the other?

[vramesh]

Dear PV,

Good question. I thought about that too just before starting with the translation.
When I was looking for the reason why some objects showed through the clouds (when Hazzie raised this issue in Hell's half acre a while back), I noted that this was happening at the lowest LOD setting (i.e. the object is just a point), i.e. when the object is close enough that it has to be shown but far enough that it is just as a point. In these cases, all the ground objects appear to show through the clouds. Upon moving a bit closer, they 'disappear' because a higher LOD takes over and if we move a bit far off, they 'disappear' again because they need not be rendered now. I don't think the version of the bin has any influence on this at all because I see this for all the objects (wheether in SHPBINs or GRPBINs or whether they are version 1 or version 2 ).
If it is the case that version 2 will introduce "objects visible through clouds" problem, then we need to choose between the lesser of the two (proverbial) evils until we find a fix for this.
Let me check on this again.
I am open for suggestions.

Regards,
Vasanth

[stickman]

Vasanth,

First of all,
I am happy to see that you did not get BLOWN AWAY....
by that fire works fiasco in south India, that I saw on the CNN news today.
A religious celebration at a temple (which was BLOWN TO BITS!) Kerama? 100+ dead, and uncounted wounded....

thinking, "I hope Vasanth was not there?"

I see that you are still very much alive after that.

----------------------------------------------------------------------------------------------------------------

My house is in a flux, and disturbance, situation right now.
My wife's two children (not from me) will be arriving soon from the Philippines.
We are busy moving furniture, reorganizing the house... and other mayhem from the grand-children!
In order to make room the these new America arrivals.

That's all OK. I moved (and reset) my alarm clock to the other bedroom.

-----------------------------------------------------------------------------------------------------------------

Will be back, soon, here.

[vramesh]

Dear Stickman,

Thank you for the concern. Much appreciate it.
I am located waaaaay on the other side of the Indian peninsula in a different state that is hundreds of kilometers away.
Suffice to say that I am very far away from the fireworks.
Heart goes out to the many innocents that are now dead.
Even sadder is the fact that this disaster could have been easily avoided.
News here report that the fireworks display was a 'competitive' one and was unauthorized!

Will be back, soon, here.

Sure. I'll wait for your feedback on the new tree1.bin. Meanwhile, I'll go glue up some new French templates for Calais.
I may be relocating to Bangalore soon(work related). Goodbye sea-shores and sunny days *sniff*. Hello gardens and mountains.
--
Vasanth

[vramesh]

Okay. According to the 3d modelers handbook, version 1 bins are called 'Rowan' models and 'version 2' bins are called VBIB models. VBIB is acronym for Vertex Buffer/Index Buffer. Got to use the correct nomenclature in the posts and discussions yes?



The translation from Rowan to VBIB does not induce the "objects appear through clouds" problem and solves the "clouds appear before trees" problem. The former may be a quirk of Merlin engine and not the object.
VBIBs and Rowan objects suffer the same problem at minimum LOD.

I am going to try two experiments:

1) Force the last LOD to NOT be a point and see what happens. If successful, objects won't be visible through clouds at cost of frame rate. This can be achieved by creating LOD_ D and LOD_E in the VBIB.
2) If experiment #1 above fails, try forcing the last LOD to a point but, manipulate its normal to point to underground and see if it fixes the "objects show through clouds" problem. If not, then wait for it to be fixed in the engine.

############################################################################

In another LOD related issue, I noted that the template bins (like the ones used to fill houses in London for example), have a strange behaviour. They first appear with low LOD, then upon moving closer, they suddenly disappear, only to reappear again gradually when we keep moving closer to it.
I think LOD_E (a point, which can show through clouds) gets loaded, then it switches to LOD_D (lines) upon moving closer, then becomes LOD_C (first appearance of buildings) then switch to LOD_B, where the buildings completely disappear and reappear gradually with the higher LOD and finally becomes LOD_A.
I think the problem is in the switch from LOD_C to LOD B.
Either that or this may have something to do with Merlin engine (I am guessing deferred rendering logic to save FPS etc.) or something else and not a problem with the object per se.

I am going to try a third experiment:

3) Delete LOD_B and force LOD_C as LOD_B in a VBIB template bin and see what happens. I expect this to partly solve the "building appears and disappear" bug .

--
Vasanth

[stickman]

Vasanth,

Okay. According to the 3d modelers handbook, version 1 bins are called 'Rowan' models and 'version 2' bins are called VBIB models. VBIB is acronym for Vertex Buffer/Index Buffer. Got to use the correct nomenclature in the posts and discussions yes?

Yes. A proper nomenclature is preferable.
I confess.. I am too ignorant to know about all this. Never read the 3d modelers handbook.

a strange behaviour. They first appear with low LOD, then upon moving closer, they suddenly disappear, only to reappear again gradually when we keep moving closer to it.

This strange behavior happens with individual objects too. The individual airfield objects do this when approaching them.
Many complaints about this in past years.

---------------------------------------------------------------------------------------------------------------------------------------------------

Looked at your new TREE1 object #62.
OK, no clouds show through it now, when on ground level looking at them, while taxiing around some airfields.

Your texture .DDS version for it is OK. I may play with it later a bit, for slight improvement.

I also may make the sh.dds texture (tree shadow) a bit more transparent.
Maybe a little too dark. Makes the fact that many other newer trees do not have shadows, show up a lot.
In some places. Not a big problem.

TREE1 #62 is the oldest BoB1 and BoBII tree. It is everywhere in game. Thousands of them have been placed in game by Developers using the ObjectAdds method of placement.
The most numerous tree of all.
For that reason, it is important that it looks good, and behaves well with clouds and lighting.

The dds textures may require some 'professional' touch. As usual, I included the dds for proof of concept. Please let me know if they don't work properly or cause any unwanted issues.
If it looks okay, then I shall proceed doing the same to 1192 beech and #1543 frst (and phare and guet and.... ).

Please proceed. The "1192 and your #1543 trees are important to do.
I do not think you need to do your Calais special objects in this fashion. They will never be used in AUTOGEN.
Most players will never see the clouds show through them, or care if they do so.

Thank you for making #62, and other trees, behave better.