не надо писать о том, о чем понятия не имеете ... ставите драйвера 306.97 (сама использую только их) и не будет просвечивать ...
Ну зачем же так грубо?.. ) Хотя в данном случае даже особого понятия иметь не нужно, достаточно элементарной логики. Есть два исходных фактора Драйвер и Енб и результат их работы - картинка с или без глюка с солнцем. Отключение Енб (даже не вдаваясь в конкретные детали, чего именно в нем) гарантированно убирает баг. Изменение версии Драйвера - кому-то помогает, кому-то нет. Вывод совершенно очевиден и однозначен - основная проблема сидит в Енб. Тем не менее, поставил ваш любимый 306.97. Как и ожидалось - эффект тот же, солнышко по-прежнему просвечивает. Полез гуглить... Первая же попавшаяся ссылка: "SunRays aka godrays из последней версии ENB. Насмешили тем, что просвечивают даже сквозь высокие горы и плотные стены..."
imiami, Вы первый, у которого не корректно работают драйвера 306.97.
Феноменальная способность переводить стрелки! ) Совершенно искренне пишу и восхищаюсь, без обид... Причем процитированное утверждение - совершенно ничем не обосновано, но как звучит! С чего вы взяли что я такой единственный и к тому же первый? У вас есть письма от всех 20000+ скачавших, и конкретно все те из них, кто используют 306+последний енб+SunRays, не имеют просвечивающего солнца? ))) Понимаете, фразы "работает отлично" и "не жаловались на проблему" - имеют совершенно разные значения... Я, например, этого просвечивающего солнца, вообще не замечал, пока не наткнулся на стартовый комментарий и не полез проверять. Кстати говоря, рекомендую для проверки ставить timescale to 300, в динамике эффект заметен лучше всего, присмотритесь, может и вы его просто не замечаете (при определенных настройках его только в ускоренном времени и можно разглядеть). PS. И, да, эти "солнечные" посты имеют абсолютно прямое отношение к теме, поскольку в составе RL использован ENB...
Я нигде не называл "это" проблемой, проблемы, как-таковой, нет, меня присутствие этого бага никак не раздражает. Просто как человек, привыкший, по возможности, доводить дело до логического завершения, хочу разобраться в чем подвох. Это совершенно нормальный процесс. Вас он раздражает - вместо наездов просто игнорируйте эту цепочку комментариев, но суть от этого не меняется: есть как минимум один конкретный компьютер (i5+GTX660) на котором при любой версии драйверов и включении SunRays в енб сохраняется просвечивание. Насчет строк в ини и корректной переустановки драйверов - все в порядке. Тем не менее, я прекрасно понимаю, что поскольку у большинства - бага нет (в том числе и на последних драйверах), то решение спрятано где-то в сочетании определенных факторов/параметров. Более того, совершенно не исключаю "человеческий фактор", что я банально где-то тупанул. Думается, что не только мне будет полезно докопаться до этого сочетания, вызывающего баг. Моя картинка (306.97+RL2 без каких-либо изменений настроек)
Докладываю итог своих разборок по поводу бага с просвечивающим солнцем. Может кому будет полезно... Баг проявляется, начиная с 320-й серии драйверов, на 314 или 306 он, действительно, отсутствует. Обещанное исправление (http://enbdev.com/index_en.htm) в версии еnb 0.188 - не проверял, ввиду немеряного последующего объема работ по настройке пресета, на что я, все-равно, не сподоблюсь. И самое главное: конкретно в моей ситуации с наличием бага даже на 314 или 306 драйверах оказался виноват Mod Organizer. При запуске игры через него баг гарантированно присутствует, независимо от версии драйвера.
Добавлено (07.07.2013, 23:13) --------------------------------------------- Дополнительная проверка (по подсказке VALKNUT) выявила проблему не в МО, а в моей памяти. У МО - собственные ini-файлы для каждого профиля. Которые я очень давно не проверял на присутствие там bFloatPointRenderTarget=1. Вопрос закрыт окончательно, приношу всем свои извинения за беспокойство.
Изменение репутации для пользователя imiami
imiamiOffline
Сообщение №247
| Тема: "Lady Body" [LB] v2.0
написано: 13 июля 2013, 08:45
| Отредактировано: imiami - 13 июля 2013, 08:46
Я правильно понял, что в итоге ГГ немного "подросла" (поскольку ниже плеч все вертикальные кости в той или иной степени удлинились)? Не вызовет ли это проблем с проходом под какими-нить низкими сводами?
для сохранения общих пропорций. Но в этом я не вижу ничего плохого. Побегайте, посмотрите ...
Проверил, встав у стены с узором - увеличение крайне незначительное, скорее всего - проблем не будет. Но сугубо теоретически (проверить абсолютно все двери, лазы, и т.п. - малореально) при увеличении роста остается вероятность нахождения такого места, в котором подросшая ГГ (равно как и НПЦ, особенно - спутники, которые сами присесть не додумаются) не пройдет в нужное место. Имхо, надежнее было бы регулировать пропорции одновременным увеличением длины одних костей и уменьшением длины других. UPD Стоп, тут я явно недомыслил, есть же ГГ-мужчины, которые все-равно еще выше (и по-определению беседки должны проходить везде). Вопрос закрыт. PS Но диадему с очками снимать не буду, голова у ГГ - одна, а шрамы украшают только... мало ли что... )
Не прав. Кстати говоря (постоянно играл с LongLegs и как-то не обращал внимание), максимальный рост почему-то в оригинальном варианте, слева-направо: только LB, плюс LongLegs, новый скелет
Спасибочки, отличный вариант. Не знаю, что именно менялось относительно предыдущего, но небо и общий уровень освещенности (к чему лично у меня были основные замечания) стали на порядок лучше.
Прежде всего следует ответить на вопрос: какую походку мы подбираем? Максимально естественную (среднестатистически) или подиумную? В первом случае плохи оба варианта: и ваниль (враскорячку), и предлагаемая. Во втором случае - предлагаемая, разумеется, ближе к теме, но также соглашусь, что виляние - слегка чрезмерно (причем там оно не столько бедрами, сколько, извиняюсь, задом, хотя насчет "в 5 раз" - это слишком сильно сказано). С другой стороны - отлично сделан вынос и постановка ноги. Насчет движения груди, имхо, на видео обливиона - однозначный перебор, который отчасти может быть оправдан опорой руки на талию, но смотрится, все-равно, чрезмерным, особенно для реалистично-скромных размеров оной груди в LB.
светло не там где хочется а там где есть источники света.
Поддерживаю обеими руками! Только так, и никак иначе. Тем паче, что есть и беседковская магия на освещение и куча модов на эту же тему. Но в любом случае свет должен появляться только от какого-то источника, а не сам-собой.
скайрим, который и без всяких енб заставит попотеть далеко не худший компьютер
Ну это вы однозначно загнули. Столь древний движок по-определению не может заставить потеть современное железо даже среднего уровня. Погуглите тесты - не менее 40fps в full-hd с 8хАА и HD на банальном 650Ti (начальный игровой уровень 150уе) А вот ENB - действительно заставляет потеть, у меня, например, при его включении (RL2 138-й) fps падает на 25% (и это еще не все эффекты включены) если ставить 188-й - дополнительно еще на 10% (с теми же эффектами).
Что на моем ноуте при 660М и i5, что на настольном при 650ой
Я, конечно, извиняюсь, но а чего вы ожидали от этих конфигураций? Для ноута - очень даже шикарно, но это все-равно ноут, что само по себе за редким исключением к игровому сегменту может быть отнесено с большой натяжкой. А для десктопа уровень 650 и ниже - это вообще самый начальный игровой и требовать от него в относительно свежих играх чего-то выше минимальных настроек - глубокое заблуждение.
Да с чего вы взяли, что не летает-то? Скайрим для своего времени - весьма и весьма демократичная игра в плане требований к железу (и именно потому, что древний движок сам по себе в принципе не может тяжело нагрузить современноое железо). Это уже тысячу раз подтверждалось всевозможными авторами... Почитайте (сугубо для примера) хотя бы http://www.3dnews.ru/video/623456 На средних! настройках для комфортной игры достаточно 6570... Не нужно грузить ваши видеокарты теми режимами/эффектами, которые им в принципе не по зубам и все будет летать.
не понимаете сути проблемы которая заключается не в видеокартах.
Я прекрасно понимаю суть вашей т.н. "проблемы". Вы все пытаетесь подвести к тому, что скайримовский движок крайне нерационально расходует ресурсы железа. Я же пытаюсь вам объяснить, что на самом деле это совсем не так. И абсолютно все независимые тесты это демонстрируют/подтверждают. Без сторонних технологий "улучшения" картинки скайрим именно летает, даже на относительно старом железе. А тот момент, что оная картинка при этом многих не устраивает - это совершенно отдельный вопрос "продвинутости" движка. Ну и соответственно, когда вы (или я) начинаем "догружать" железо сторонними эффектами, то игра совершенно закономерно начинает терять фпс. Но еще раз - к недостаткам производительности движка это никаким боком не относится.
когда игровой движок маленькую текстуру растягивает на больше разрешение - так и получается. Текстура не резиновая - ее нельзя растягивать.Только уменьшать ... тогда она не потеряет качества. В идеале - текстуры всегда должны быть больше игрового разрешения.
Вы упускаете самый важный момент - родное разрешение жк-монитора. Все наши прочие ухищрения с качеством картинки абсолютно теряют всякий смысл, если в итоге монитор начинает пытаться представить, например, 3 логических пиксела 2-мя реальными (физическими). Если мы не хотим "потерять все, что заработали", за жк-монитором обязательно! нужно работать в родном его разрешении. И только после этого можно уже ловить всех прочих блох...
хм ... как же у меня получается играть на 1600х900 ... а родное разрешение монитора 1920х1080?
Да выставить неродное разрешение - не проблема, проблема получить при этом то, что хотим... Задумайтесь: есть подготовленная видеокартой картинка 1600*900. Возьмем одну ее строку - 1600 пикселов (каждый со своими параметрами цвета и яркости). А выводить их надо линейкой из 1920 физических пикселов... Как это будет делаться? Один вариант, который не приведет к потерям качества - отрезать ненужные пикселы, т.е. вывести на экран именно нужные 1600, а остальное - черная рамка. Но так многие мониторы вообще не умеют делать. А если начнем растягивать - то и получим, что монитор сам начинает рассчитывать интерполяцию, а поскольку процесор и алгоритмы в нем - весьма унылые (по сравнению с видеокартой), то получаем мыло, потерю резкости, искажение цветовых переходов и пр. и пр... Я уже молчу, что для глаза нашего это тоже никак на пользу не идет. Только хардкор - родные 1920 (в вашем случае) Попробуйте поработать в винде при неродном разрешении - гарантирую, что через пару часиков глаза начнут слезиться и побаливать...
Чет не заметила, чтоб моя картинка уступала картинкам 1920х1080:
Гм... вы опять наступаете на те же грабли со скриншотами Скриншот - это копия буфера видеокарты, в нашем случае он НИЧЕГО не показывает, все мы видим его не таким, как видите его вы. Одно важное уточнение - все сказанное мной относится к полноэкранному режиму. Если играть в окне (меньшего размера, чем разрешение монитора) - все ОК.
так я и играю в полноэкранном режиме и не вижу разницы ... если бы была разница, я бы уже давно бы занялась решением этой проблемы, поскольку очень трепетно отношусь к качеству графики.
Отвечу вам вашими же словами: то, что вы ее не видите, еще не означает, что ее нет. Физику процесса я выше изложил, погуглите, если угодно еще, но ничего другого вы там не найдете: картинка на жк ощутимо портится при неродном полноэкранном разрешении. Хорошо еще, если там целый множитель получается, например картинка 800*600 на 1600*1200 мониторе, а ежели множитель нецелый - совсем грустно. Это не ЭЛТ, где можно было творить, что угодно... И тут нет никакой проблемы, просто где только можно - использовать родное разрешение монитора и делов-то... Поберегите ваши глазки...
это если маштабирование выполнять на мощностях монитора. Н-видиа позволяет это делать на ГП.
Не столь принципиально. Еще раз: при работе за монитором в неродном разрешении, мы сначала заставляем потеть видеокарту, накладывая нужные нам эффекты. Получаем на выходе правильный кадр, в котором каждый пиксел имеет строго определенные параметры. И тут выясняется, что нам еще нужно не просто вывести этот кадр попиксельно, а еще раз этот кадр обработать, дабы представить правильный массив 1600*900 реальными 1920*1080 пикселами. Даже при использовании продвинутых алгоритмов растяжки, этот итоговый массив однозначно будет состоять из совершенно других пикселов. Как бы мы ни старались, это по-определению будет уже другая картинка! Для банальных заливок одним цветом - особых проблем нет, но как только речь заходит о разноцветных соседних пикселах (коих на нашей игровой сценке немало), все значительно усложняется. Кардинальным выходом из этой ситуации был бы изначальный расчет картинки видеокартой с учетом не только выставленного разрешения в игре, но и физических параметров монитора (т.е. мы ставим 1600*900, но видеокарта молча заменяет их реальными 1920*1080), но я никогда не слышал о железе/драйверах, которые бы могли так работать. Да и при таком подходе возникает куча своих проблем, особенно для многомониторных конфигураций. Я не хочу сказать, что на самом деле все очень плохо, в динамике игры искажения от растяжки могут вообще быть почти незаметны. Но ежели подключить к видеокарте два монитора с разными разрешениями и подать на них в клоне статичную картинку с разрешением, родным для меньшего монитора - разницу не заметить сложно.
Но не могу сказать однозначно, что она в лучшую сторону...
А это сугубо по той причине, что, фактически, вы все это время (работая на 1600 при родных 1920) просто оптимизировали картинку под свои глаза-мозг именно с учетом постоянно включенной постобработки 2D-кадра монитором. Чтобы получить однозначно лучший (для вас) вариант в родном разрешении, нужно с нуля повторить весь этот процесс для 1920 . А насчет детализации (четкости) по всему кадру и свойств фокусировки человеческого взгляда - мы уже обсуждали. Тут вы тоже не совсем правы. Да, глаз видит в фокусе только ограниченный угол, все остальное - боковым зрением (фактически вне фокуса, ловя только само наличие там объектов). Но! Предлагаемый для имитации этого эффект размытия картинки не по центру экрана - еще дальше от реальности (и страшнее для здоровья). Поскольку в реале, перемещая глаз на периферию, мы автоматически помещаем этот периферийный объект в фокус. А перемещая глаз по такой размытой по краям картинке (не мышку двигая, а глазами!), мы видим мыло, что совершенно чуждо природе зрения и ничего, кроме вреда глазам не приносит. Единственным спасением в этом случае может быть режим игры, когда мы тупо смотрим всегда в центр экрана, а необходимость посмотреть в сторону заменяем именно перемещением мыши. Но этак недолго и привыкнуть, и в быту начать заменять движение глазами - движением руки...
для справки: любой профессиональный рендер специально размывается, убирается детализация и на него добавляется шум и блур, чтобы зритель его воспринимал боле естественно
А где я спорил с этим? Именно это я имел ввиду, говоря, что вы оптимизировали картинку уже с учетом дополнительного размытия от монитора. И все, что требуется для такого же эффекта, но на родном разрешении - повторить процедуру подбора эффектов/параметров, но уже при родных 1920.
Это очень на любителя... Опять же нужно различать постановочный скриншот и реальный игровой процесс, в котором зачастую заметность того самого "муравья вдали" - огромный плюс, поскольку оный муравей - это на самом деле был редчайший артефакт, пропустив (не заметили - не подобрали) который мы очень много потеряли в игровом плане.
Поддерживаю обеими руками (за исключением орфографии ). И с маленькой оговоркой, упомянутой выше - это все-таки игра, а не фоторепортаж. И многие (если не большинство) играют ради геймплея, а не фотореализма.
Мы Вконтакте
Цитата автора: 
Н-видиа позволяет это делать на ГП.