z929669

There are lots and lots of textures for CBBE (see BI Phenotypes for starters) ... also, I think the CBBE nevernude option allows us to use any nude textures without needing to worry about undies :P

@Kryptopyr The body is changing when equipping armor (I chose Forsworn, since it is one vanilla armor likely to reveal body-mesh incompat ... if you look carefully at the belly, upper arms and chest, you will see that the body does change. there are just no seams). It turns out that the vanilla-type CBBE body maps nicely to vanilla-type forearms and ankles. @Tech BHB will not affect body shape, since it is only a normal map ... and it is applied to the CBBE vanilla mesh in those screens already. I also don't like the ribcage, and that is a combination of the mesh and the texture mapping. I have a whole gamut of testing to do with many different texture sets as well as mesh alterations using bodyslide. Goal is to create a combo that works with STEP-vanilla and also looks good. Then we can bundle as a mod (at least the mesh anyway). XCE has some great face/head improvements that are also lost with CBBE and other body mods. Unfortunately, XCE color is corps-ish. Lots of testing yet to do.

I am currently working on the female body solution for STEP. It looks like CBBE should work as a vanilla replacement, and there are a great many options for it. Here is a sample demonstrating how it looks: Current STEP > CBBE (with modifications) > CBBE with vanilla Forsworn armor

You are misinterpreting him. Try not to be so defensive, and consider that he answers lots of questions as the developer. I can understand your frustration and the potential to misinterpret, but Tannin's post is obviously does not contain a personal insult (although you may have been insulted) ... your post does. He was just being precise in identifying the likely issues and correcting any misinformation that might be gleaned by other users perusing this thread.

Yes, I was referring to his limited and less-than-crystal-clear response. I agree that it is enough to be confident that EnableCompression does not act on data within VRAM. It is good that this is 'True' by default, because that way we don't need to even mention it in the ENBoost install notes (but detailed descriptions will still be needed for this and all other settings in the ENB Guide). I am a big fan of "less is more" ;)

After doing some testing, I can confirm that there are no longer any frame rate glitches for Try fast left/right movements in both first and third person view and compare with/without the mod active. This mod adds a bit of inertia where it did not exist previously. In other words, stopping, starting, changing direction, going uphill/downhill include some degree of momentum where it would otherwise not exist. This translates into a slightly more realistic experience, but I also found myself feeling as if I were in a dream and trying to move or run and being somewhat restricted at times. I will need to play with it active for an hour or two and then deactivate to see just how my movement is impacted. Then I will be able to make a final judgement. ... will I feel 'freed' or will I feel unrealistically 'reactive'? My first impressions are good.

Thanks for getting confirmation (sort of anyway). Looks like you were correct and my assumptions were wrong. Definitely not the first time for either! Based on this, we should recommend compression be used by default, unless running 64-bit with at least 8 GB RAM (with caveat that this will not apply to everyone). What is the default setting? True or False?

I removed Dynamic Fires from the 2.2.9 guide. You just need to go into the Form and edit the source code accordingly.

Not necessarily for next release. Just putting it out there

Altimor contacted me on the Nexus and says that the FPS bugs are now fixed. Need to retest for STEP

This apparently also conflicts with SDO and has reported issues with regard to putting out fires that should not be put out, so I think it should be dropped. Not sure how this one got into STEP in the first place, but my bad.

We should drop Dynamic Fires, given the associated bugs.

Best Answer feature should now be available for that forum

Unfortunately, much of what Boris says is not qualified or presented out of context. I find most of his posts confusing ... I translate this to mean that when textures required for situational cell-loading exceed VRAM capacity (or when all needed info is not in VRAM at the given moment of the need), then sys RAM info is needed, and that has the additional lz4 compression overhead. This all corroborates the idea that the lz4 compression is distinct from texture compression, and ENB's lz4 compression is applied to information contained within TESV and ehbhost processes; however, some proportion of info contained within TESV (and possibly enbhost) process is also contained within VRAM, so I am supposing that 1z4 compression may not be restricted only to sys RAM (but that may be where it lives predominantly). This is very confusing. It seems like he is answering a question, so it is unclear if it was "should I ... ?" or "should I not ... ?". What do the various references to 'this' and 'this mode' refer to?? EnableUnsafeMemoryHacks=true/false ... something more not in this post ... ?? Very unclear to me. Again, loading from where exactly?? VRAM or sys RAM or both? Knowing source is very important to gleaning the EnableComression theoretical effects. So this seems to be saying that lz4 compression is predominant in enbhost process and secondary in TESV process? What about additional enbhost process(s)? Very unclear to me. This kind of interpretation could be placebo. Need actual data. Possibly, but that would imply that VRAM can contain the lz4 compressed info too (if it is true that video memory from TESV process is redirected preferentially into VRAM and enbhost process secondarily.) But I suspect it is (see previous comments). Lots of good progress though. Just a few kinks that still bother me (I want to correct the info in the ENB guide).

This is about as clear as mud, and I disclaim any responsibility for that wording. I am certain that it is semantically inaccurate and misleading. Unfortunately, there is a lot of info on our wiki that could use revision and clarity. Better to simply state that setting to 'true' will minimize use of VRAM for those that need it, but it will come at the cost of processing time to render graphics, leading to stuttering at times. I in fact do not know this to be true or not, but I have plenty of VRAM and sys RAM for ENBoost to work with. Needs testing to confirm, but that is the gist I think.

Indeed, that post is one I link users to as well. Here is another useful reference. Tri buffering is key, and vsync is not bad with it enabled ... I suspect that ENBoost includes tri-biffering with supported cards (at least that is what my frame rates are saying to me, since I typically get around 35-50 outdoors with ENBoost vsync enabled).

I should also note that the images I posted previously don't show it, but I did not notice any seams in my testing .... but I did not look super hard either, so that is testament to the basic idea that it does not matter unless the seams are obvious without a closeup shot and a lot of scrutiny. Even Techs examples earlier were of little consequence IMO. Those terrible vanilla meshes around hands, feet, inner thighs and armpits are much bigger issues, and XCE does not fix all of them.

There is no need to use the frame limiter with vsync. I also can not fathom any reason why enblocal.ini vsync would not be working. Your enblocal.ini is atypical as well ... lots of settings that don't belong in there and comments that are not typical. I have seen strange things happen with character encoding in text files too. I recommend updating to latest enbseries and using a fresh enblocal.ini.

OK, finally getting around to this. I wanted to look at the vanilla-XCE-CNHF compares first hand for starters. The results are that I officially hate have some serious reservations about the female body now :| 3 poses: vanilla > XCE > CNHF Even with XCE, the vanilla body has some big drawbacks for me ... check out the armpits in the back shots. I never liked that horizontal belly fold either. Realistic for a post pregnancy housewife, but not an ass-kicking, strong woman of Skyrim. Vanilla facial scars are better than XCE though. CNHF body is very good. Only the arms bug me (shoulders look great though). Like vanilla, they are too mushy looking and lack the elegant curve that any normal arm has (male or female). From the front, the arms just look like they have been broken a few times or that they belong to a once obese person that has had lipo and skin reduction surgery. I did increase their size a bit though during char creation. From the back, the CNHF arms look fine though. XCE definitely has issues with grayness though. Unfortunately, XCE facial textures are superior with regard to sheen and detail though. Alas, they are too gray to mix and match with alternate body textures.

Totally understandable that you want to first address the lighting base, since that can drastically influence all of those little details. I gave up tweaking them due to the base changes you guys are making! (all for the better though, so keep up the good work and let us know when you are 98% done with that ;) ). I am expecting Vividian to become quite popular (it kinda is already)

Yep, I am z929669 on Git ;) You can friend me or whatever out there

I may be able to 'fix' the textures and post to Nexus. Still need to test though (finalizing my 2.2.8 update)

OK, I do not have permission to sync to your master. I also cannot create a new branch to commit to. You should probably open this up for broader contribution ... corrected RaedMe attached. (I also fixed some indents and spacing to make it easier to read. no other content change, and I did not replace the tabs, since this probably helps you to edit.) Readme.txt

OK, I'll simply remove from the ReadMes and sync to Git. Thanks for confirming!

Based on this thread feedback, I don't think there is necessarily a problem with the Campfires plugin .... ?