View Full Version : [TEC] Rendering through optics vs external view issues
Anyone here grok the optics in SH4?
As JMM progresses, we've had a few odd rendering problems with textures, but invariably it's only for SOME views.
Before, we had a damage issue where damaged ships would show odd textures, but only through the binos and deck gun sight. External? Fine. Periscope or TBT? Fine.
Those got fixed, now it looks great except... periscope and TBT.
I have some minor shimmering (light colored) with the periscope, for example, but if I try it in stock SH4 1.4, I don't see it at all.
Before I try all sorts of other testing, maybe someone else has a clue.
Nisgeis suggested to me on a previous problem (which we thought was fixed) that it might be Z-fighting.
How can I avoid this?
It happens with damage, but the damage models are not co-planer with the hull areas that show the effect. The base B and F models are, but they are mapped OK (seemingly), as is the reflect model.
Solutions?
1. make the other models slightly smaller?
2. is it an LOD issue? Is the game fighting between a low LOD because of camera distance vs closer due to the 'scope?
I did a test mission, and a "stock" ship does this as well in RFB, at least through the binos.
Our ships have no isses with the TBT, but do with binos.
Stock 1.5, zero issues.
So it must be related to camera/environment mods.
I have tweaked a lot with camera zooms and aperture angles, and never suffered such problems. My guess is that reflections (As part of the environment mod) might have something to do with this. The bad colour/texture seems more logically rooted to that.
Yeah, in some other posts and PMs I've been generalizing to "environment." Though partially because I know squat about what those mods mess with.
I did a test with TMO last night and while there, it is far less profound than RFB.
No one understands the environment mods?
Ducimus
09-09-10, 08:57 PM
A quick way to narrow down possilbiites, is to run whatever instance your seeing the most profound shimmering in,..... with a stock scene.dat.
If the shimmering goes away having done that, then its something specific to.. im guessing reflection settings. (regardless, its something specific to that file) If it does not, then assuming its still an enviormental problem, then its a shader file somewhere.
Process of elimination. Start replacing suspect files with stock versions (or versions known to not have the problem), until the problem goes away. Once it does, you have your cause. Once you find the cause, then you can work on a fix.
Gotcha, that's a start. Can you tell we want to kick this thing out the door?
:D
Ducimus
09-09-10, 09:38 PM
Yeah, your chomping at the bit.
Can you tell i've done alot of trial and error troubleshooting? :D
Problem is that this mod is BIG. I want to test with all the new stuff loaded so I can sort out any same-ID CTDS in the dats... the mod is hundreds of megs. It's ~250MB zipped since there are ~32 new dds files per ship, plus dats, etc.
That means the load time in JSGME is at least as long, or longer than the time to crank up SH4, select test mission, then load THAT. The in and out of game blows extra big time as a result.
Ducimus
09-09-10, 10:53 PM
Hmmm...
Protip:
Work with your mod in smaller chunks. Create several "modlets" by topic or area, and use naming conventions for the mod's root directories.
Examples of my JSGME mod list by memory:
TMO2.0
TEX_NewInterior
DAT_NewInterior
DAT_ASW
CREW_GFX
CREW_UPC
SUB_DatSimZon
SUB_UPC_EQP
ENV_SceneDat
ENV_Shaders
UNITS_AIR
UNITS_Land
UNITS_Sea
UNITS_Sea_TEX
etc etc. I think you get the idea. Don't be afraid of overwrites, JSGME becomes a tool in itself.
Doing this does several things.
- greatly reduces load time and hard drive thrashing from constant mod enabeling. You only enable what your currently working on, not the whole damn thing.
- makes it easier to revert or test changes
- makes it easier to write up a freaking changelog later. :shifty:
WHen your done and ready to publish, you just create a new JSGME mod, an copy (Or move if your feeling confident), the data directory from each modlet to your new root mod. I refer to this as "compiling". Test your compile, toss in the read me, 7zip the Mo'fo' , upload, profit.
Ducimus
09-09-10, 10:59 PM
Oh yeah, for your purposes of textures. You could always sperate your textures by ship type.
example
TEX_unit_DD
TEX_unit_DE
TEX_Unit_Cargo
TEX_Unit_Tanker
TEX_Unit_Capital
be creative.
I could divide the ships up by class (merchant/tanker/transport), but other than that, I only divide NEW ships vs standard ships.
When I add nodes to, say, taihosan, I need to check with all of them to make sure I didn't dupe an ID randomly.
On stuff like these new ships (ada, aden, ansuyu) I make a mod for each ship to minimize the loading/unloading. I put new ideas in a modlet, too. I actually have a template mod with all the folders I ever use there, but empty (Roster with sub folders, Sea, Library, Campaigns, etc.
Scene makes little difference. I saw it, but it was back to deck gun, but also periscope.
I tried stock cameras... and saw no poor texture effects at all with TMO.
That makes the most sense since the problem has manifested itself with z-fighting only with SOME cameras as I said. First with just binos and deck gun, then with only 'scope and TBT.
Stock cameras and I see no shimmering or weirdness.
Nisgeis
09-10-10, 02:02 AM
Does it happen at all ranges, e.g. if you are close up do you get the same effect as you do when you are at a distance?
I need to check. One thought I had was that it was between 2 LODs. As I said though, when I just tested with TMO and the stock cameras.dat, there was no problem at all.
So it's cameras.dat.
Hmmm.
It DOES show problems with the stock scene and cameras, but my previous tests were flawed.
The range is critical.
At closer range, it shows no problems at all with stock scene and cameras.
At long range, it DOES show the problem, but the range at which it changes depends on what the game had seen previously.
Meaning I damage a contact at longer range (couple thousand yards). If I close the target, the texture problems get slowly less visible as I close. At 1300 or so, they get better faster, and by 950 yards they are not happening.
One I am within that 950 yard range, if I then back away and open the range, it doesn't get worse. I let it go out towards 2000 before I quit for testing later.
So the transition from higher LOD to lower doesn't show the problem, but at long range it does. (my previous tests I fired close enough that it never showed)
The effect varies in terms of which camera you use, too. It's always fine in external, and the deck gun usually shows the problems first.
Nigeis, I don;t have a "stock" version for real play, but the working version doesn't crash or anything, so I can send it to you if you have any ideas.
What is the "clipping distance?"
Madox58
09-10-10, 06:32 PM
I would think it's a Game limitation involveing Octrees.
:hmmm:
The rendered and non-rendered partion of scenes is conflicting
depending on the Cameras involved?
Also.
Check to be sure no model or object has been set as
double sided!
All SH Games hate double sided objects.
I would think it's a Game limitation involveing Octrees.
:hmmm:
The rendered and non-rendered partion of scenes is conflicting
depending on the Cameras involved?
Also.
Check to be sure no model or object has been set as
double sided!
All SH Games hate double sided objects.
Roger that, will check, immediately!
I looked, and all the stock SH4 ships apply a 2-sided texture tot he damage model. The reflect models are already fine (1-sided).
On a lark I set the damage models inside to use the 1-sided texture instead of the 2-sided used in stock. No dice.
I should add that the very first thing I checked was to make sure the damage texture had a lower ID than the damage models themselves. No dice there.
Will check the model (though when I looked last it looked 1 sided)
Madox58
09-10-10, 07:23 PM
2 sided is a 3D setting in most programs.
It's easy to set something to 2 sided and then forget when exporting to Sh Series of Games.
(I still do that now and then!)
It may not be the problem.
But it is something to be aware of and check to eliminate possible problems.
I didn't see that in wings, though the normals look OK. I'll see what it says in misfit.
I can't seem to find a way to check models for sidedness in wings 3d, or misfit.
Could the N maps have any thing to do with this?
All the normals look OK.
I tried lower rest O maps (same as stock). No dice.
I tried bumping the distance before the low LOD only uses the sun. No dice.
What is the "clipping distance?"
It's the distance from the camera that objects will be "clipped," aka, not rendered. Important for using items like the TBT.
I'm trying to figure out why I am seeing this.
This is all LOD. It is NEVER seen at High res, only when the object is distant. It varies with different mods and cameras only because the magnification then makes them appear to be at different LODs. If the mag is enough to make it use the high-res, there is no problem.
I can try bumping the LOD range, but that could seriously hit frame rates.
http://www.subsim.com/radioroom/showthread.php?t=136354
reference
Anyone understand shaders?
Nisgeis suggested changing the clipping distance to 5 in cameras, and it works.
The trouble is that this is a "work around," I'd still like to figure out why it behaves differently than stock.
Madox58
09-14-10, 05:17 PM
Could you send me a link to the files?
I can probably do more by actually looking at them then kind of guessing.
:hmmm:
And I do have a fair amount of good software for 3D stuff.
PM sent!
Appreciate you having a look.
:yep:
Madox58
09-14-10, 06:07 PM
Looking now.
:hmmm:
Is there any area that shows the problem the worst?
I'm getting ready to release a ship so that someone can maybe try and help with this. I'm at my wit's end.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.