Потому что С# писался после java и они знали на какие грабли лучше не наступать дважды, а core в java от версии к версии не переписывается, а дописывается.
на каждом новом этапе мы как минимум приводим число к четному и на следующим оно в 2 раза уменьшается, при этом уменьшаться может несколько раз подряд, а увеличение в 3 раза несколько раз подряд идти точно не может...
Подозреваю, чтобы оно точно стало не простым... Если в формулировке задачи было - берем любое непростое число - это чуть чуть сложнее, чем берем любое число и умножаем на 3. Хотя можно по программе проверить - работает ли гипотеза при умножении на 7 например ...
svoysredychuzih.livejournal.com/119943.html — вспомнил из прошлого анекдот, я первый раз его в 2004 году увидел. Очень похож подход дельфиста, кстати с тех пор к дельфистам остался стериотип из анекдота…
Ну не суть.
Для меня большая разница между тем, что тогда и тем, что сейчас — интернет, а именно легкость к получению большого кол-ва разностороннего материала.
Уже на старте, и сейчас и тогда, наверное, каждый понимал, что есть проблемы с защитой, с ресурсами, с универсальностью, с производительностью.
И если не брать случаи, когда хотят просто по быстрому срубить и свалить и больше не начинать, то каждый уже сам осознано принимает решение.
«Да, я понимаю, что в моём проекте много дырок, но кому он нужен», «Да, оптимизацией с точки зрения производительности не занимался, но он и так пойдёт, а дальше расти не будет», «Да, проект запуститься только у меня и на таких же кранах, как у меня, ну и больше никому не надо ...» и так далее.
Если же не так, то как минимум будет поиск —
Ddos атаки, как избежать
уязвимости сайтов
java/php/c#/…. best practice
UI/UX/адаптивный дизайн
Чисто теоретический вопрос, чтобы понять есть ли какие то очевидные неточности в следующей достаточно топорной логике:
Если предположить, что камера не движется быстрее чем снимает и что резких действий произойти не может, то возможно для нахождение и отличие шумов, движения камеры и… стоит искать не движущее изображение, а искать максимально схожее изображение (то есть, последовательность точек)…
Соответственно, чисто теоретически
Если камера движется или не идеально зафиксирована, то по контрольным точкам понятно на сколько куда она продвинулась и можно соответственно скорректировать. Она же не может частично двигаться.
Если появляется лишний свет/блик/тень, то это влияет на все точки в области и так же можно скорректировать. Свет же не может отразиться только 1 точке, по идее он отразиться на всём изображении так или иначе…
Каждый кто программирует на Objective-C и на C# знает, что первый отставал от последнего на два десятка лет.
совсем непонятна.
Первый — это Objective-C, как он может отставать от C# — на два десятка лет, если C# всего 14 лет?
Это подразумевается, что он старее? Типо старьё ))) Или что он с тех пор не развивался, а только в недавнее время стал развиваться?
Я C# к сожалению профессионально не занимался, но когда на курсах изучал, нам там прямо сказали, C# полностью всё ворует у Java и учиться на чужих, то есть java вских ошибках… Не знаю на сколько это имеет место быть, показалось достаточно забавным…
Каждый кто программирует на Objective-C и на C# знает, что первый отставал от последнего на два десятка лет.
Для тех, кто в танке… В каком смысле «отставал»? Второму же всего чуть больше 20 лет ))) Как же «первый может отставать», он что только что появился? ))))…
В пользу второго можно сказать, что ко второму постоянно придумывают новые framework-и, которые сильно облегчают жизнь… Это не столько развитие общей структуры кода, сколько чисто заточенные вещи под мобильные устройства и не только устройства…
Я просто не знаю, что в этом плане может нам предложить «первый» ))).
При создании коммерческого ПО сейчас используются обфускаторы или сейчас все пошли на open source? Как они совмещаются с динамическим мета программированием? Можно часть кода оставить «чистым», а часть обфускарнуть?
Я пока запостил всё со всеми комментами (и в целом и каждой строчки в отдельности) на gitHub.
Только пока не знаю как русский шрифт подключить.
Изучаю. Как получится подключить — дам ссылку, отсюда всю простыню заменю.
Там же ещё сделал небольшие исправление — что то вроде наследования для всех примитивов.
Подправил код с учетом замечаний. Плюс — убрал создание и компиляцию шейдеров в инициализацию холста. До этого она была при обрисовке (у меня на компе не тормозила и так, теперь очень быстро работает и на слабом рабочем ...)
Добавил немного комментариев.
Я код указал в конце, как это называется — «для ленивых», чтобы можно было сразу проверить, а что собственно из всего этого получится… А до этого прописал, как рассчитываю координаты, может не столько подробно, хотя мне кажется, что я даже переборщил, в смысле описывал вещи, которые и так очевидны. Как зная центр ширину и высоту построить прямоугольник )))… Хоть это и очевидно, я это написал, как пример, что я понимаю под «примитивами» и что для меня означает идеальный вариант… И мне очень сложно понять, зачем строить систему, в которой каждая вершина бы прописывалась, а не рассчитывалась, даже у простых фигур, не говоря уже о сложных.
По поводу сферы, у меня был внутренний восторг, потому что на самом деле не мог предположить, что так всё легко и просто… Про себя чертил там соединял как то вершины, пытался найти какую то мнимую зависимость, а тут всё так легко и просто… Но я не знаю, как этот алгоритм подробнее расписать.
А в коде той же сферы, большая часть — это очень вспомогательная часть, которая только помогает построить…
Но не представляет из себя интерес в плане самого решения. Например, создание копии объекта, соединение разных прямоугольников друг над другом, расчет угла на который надо поворачивать и кол-ва итераций — это всё необходимо, но это не имеет смысл расписывать.
И напоследок, я внутренне очень сильно уверен, что если вы возьметесь реализовывать даже тот алгоритм построения сферы, который я дал, у вас реализация и в коде и просто алгоритмом будет намного лучше…
Я у своей сферы нашел один небольшой недостаток — 2 прямоугольника, назовём их условно юг и север множатся n-раз, где n — это 360 / кол-во прямоугольников… Или около того ))).
gitHub…
Спасибо, буду использовать.
P.S. На самом деле вся критика очень конструктивная. Мне кажется, что тяжело было не выругаться сильнее.
P.S.S. Если развивать данную идею, то можно создавать «скелеты», то есть просто расчет вершин через 1 точку центра… Мне остается в коде контролировать только центры. Таким образом облегчается задача создания зависимостей между центрами и построения того же самого «человека»…
Материал рассчитан на начинающий уровень, для тех, кто прочитал основы webgl и хочет попробовать начать работать. Таких как я.
Дальнейшее развитие — это прежде всего работа над ошибками. И всё остальное уже прийдёт после того, как чуть больше изучу тему webgl.
Если абстрагироваться от ошибок, финальной частью данной серии я бы поставил — размещение объектов на карте. Как самый первый вариант реализации, который приходит в голову — это выбор примитива (описаны в 3-ей статье), может через список, может через кнопку — ввод минимальных данных (размеры, радиус) и размещение на карте — canvas 2d…
Я чувствую меня тут повесят ))) Но зная про матрицу проекции, я бы при перемещении по карте при повороте персонажа — разворачивал бы всю карту, ну на самом деле этот вариант кажется самым простым, только не самым производительным ))). Не буду я так делать, честное слово!
«последовательность точек, примитивов и прочей геометрии» у меня тоже рассчитывается через матрицу, а не вбивается вручную ))). Загвоздка как раз была в этом.
Как идея, чтобы учесть общие замечания. по сколько они сводятся к одному… Это найти способ описать инструкцию формирования примитивов по минимальному кол-ву параметров через данные которые можно передать в шейдеры.
Как самый «топорный» вариант я могу пользоваться своим алгоритмом, чтобы сохранить «последовательность точек, приметивов и прочей геометрии» где-нибудь а потом от кудо-нибудь это всё использовать.
При обрисовки сферы, правда с очень хорошей детализацией (то есть её можно без сильной потери уменьшить в полтора раза) у меня в массив индексов попадает 7200 значений, уменьшив их будет 5000, среди них около 600 (это я очень грубо) лишних, ну это я оставляю для тех, кому интересно найти ошибку в алгоритме сферы…
4400 точек… Ну сам я их буду вбивать…
А так вроде всё нормально…
И она никак не закрыта от GLSL, если надо её перемещать, поворачивать использую все прелести большого кол-ва ядер GPU — никаких проблем…
У меня просто эта сфера и на JS не то что летает, это какой то сумашедший шарик…
Пока для теста использую requestAnimationFrame
Так вот он только на первых 10 секундах плавно, а потом…
При работе над ошибками
rotateByX, rotateByY и rotateByZ — Я эти методы добавлю в примитивы.
Пока у меня у примитива
есть методы
rotateAroundCenter, rotateAroundPoint, rotateAroundMaxPoint, rotateAroundMinPoint, мне просто пока как то так легче, чем если сделать
rotateAroundCenterByX, rotateAroundCenterByY, rotateAroundCenterByZ, rotateAroundPointByX, rotateAroundPointByY, rotateAroundPointByZ,…
Можно, конечно оставить просто rotateAroundPoint и для него сделать эти приставки, но я старался вводить минимум координат. Как мне кажется, система вообще не должна от них зависеть.
По поводу идеальной матрицы…
Я пока до конца не понял.
Подумаю. Мне пока, пока я не дошел до «карты» и «общего мира» не требовалась матрица проекции. Скорее всего при дальнейшей работе столкнусь с данной проблемой, буду иметь виду это замечание.
Я использую данную матрицу не только для перемещения объекта, но и для первичного подсчета координат объекта. В дальнейшем нет никаких затруднений данную матрицу совмещать с GLSL механизмами, так как по мимо всего прочего у матрицы остается — .source.
В остальном прошу прощения и спасибо за критику. Меня сподвигло написать серию статей приблизительно следующее:
В «стандартном уроке» от сплошного кода автор начал делить на функции, я решил чуть чуть развить тему упрощения.
Воодушевленный успехом, а особенно когда получился примитив — сфера (я не думал, что он так легко и быстро получится), я решил поделиться простой мыслью.
Холст — примитив — совершаем операции — добавляем — рисуем.
И на каждом из этих этапов — используем только необходимый минимум входных параметров.
Весь код — это возможно грубая, но просто «черновая» реализация данной идеи.
Это не то, что я должен каждый раз лесть во внутренний механизм webgl, если хочу добавить какой-нибудь объект.
В дальнейшем естественно буду улучшать — с учетом критики в этой и предыдущей статье, а также по мере изучения webgl.
Спасибо за то, что дочитали и за критику.
Основная задача была сделать инструмент, в котором при минимальном описании можно было создавать 3d объекты… Это то, что в последней статье выдвинуто в функцию windows.onload.
var scene = new Scene("webgl");
scene.setBackgroundColor([0.1,0.5,0.6,0.2]);
scene.setViewPort(300, 300);
var circ = new circle([-120,-70,0],60,30);
scene.AddObject(circ);
scene.draw();
А что может быть легче?
На будущее остается только создать инструмент, чтобы располагать примитив на карте, а не вбивать координаты.
Внутренняя реализация возможно не самая лучшая ))).
Никого не учу. В данном случае, главное — идея, я же не делаю коммерческий продукт. Перед тем как публиковаться идею реализовал, ну почти полностью, всё кроме общей карты ))). Естественно, если интерес останется, после полной реализации на данном этапе буду убирать всё лишнее и добавлять новое.
1.attributeSetup — данный метод — «заточка» на будущее, если вдруг мне надо будет подвязать атрибут при этом ничего не меняя или сделав минимум изменений в самом Scene. Пока я этот метод не вызываю.
2. enableVertexAttribArray по поводу attributeSetup уже написал, по поводу initProgram — обшибся… Я ещё добавлял буфер с матрицей раскраски, из «стандартного урока»… Забыл убрать. На самом деле, пока не знаю, как лучше добавить атрибуты.
3. Осталось от отладки. Исправлю.
4. А я не знал, что это выкрутасы ))).
По поводу самого вопроса «есть ли возможность» — речь идет о загрузки дополнительных вершин… Я понимаю, что есть STATIC_DRAW, есть и другие способы и обойтись можно 1 буфером.
Как я понял по вашему комменту способ всегда был и есть. Меня просто немного смутило
«When a buffer is bound to a target, the previously bound buffer for that target is automatically unbound.».
Потому что С# писался после java и они знали на какие грабли лучше не наступать дважды, а core в java от версии к версии не переписывается, а дописывается.
на каждом новом этапе мы как минимум приводим число к четному и на следующим оно в 2 раза уменьшается, при этом уменьшаться может несколько раз подряд, а увеличение в 3 раза несколько раз подряд идти точно не может...
Подозреваю, чтобы оно точно стало не простым... Если в формулировке задачи было - берем любое непростое число - это чуть чуть сложнее, чем берем любое число и умножаем на 3. Хотя можно по программе проверить - работает ли гипотеза при умножении на 7 например ...
Людей впринципе будет меньше.
Ну или больше, как повезет.
Вряд ли останется столько же.
Ну не суть.
Для меня большая разница между тем, что тогда и тем, что сейчас — интернет, а именно легкость к получению большого кол-ва разностороннего материала.
Уже на старте, и сейчас и тогда, наверное, каждый понимал, что есть проблемы с защитой, с ресурсами, с универсальностью, с производительностью.
И если не брать случаи, когда хотят просто по быстрому срубить и свалить и больше не начинать, то каждый уже сам осознано принимает решение.
«Да, я понимаю, что в моём проекте много дырок, но кому он нужен», «Да, оптимизацией с точки зрения производительности не занимался, но он и так пойдёт, а дальше расти не будет», «Да, проект запуститься только у меня и на таких же кранах, как у меня, ну и больше никому не надо ...» и так далее.
Если же не так, то как минимум будет поиск —
Ddos атаки, как избежать
уязвимости сайтов
java/php/c#/…. best practice
UI/UX/адаптивный дизайн
Если предположить, что камера не движется быстрее чем снимает и что резких действий произойти не может, то возможно для нахождение и отличие шумов, движения камеры и… стоит искать не движущее изображение, а искать максимально схожее изображение (то есть, последовательность точек)…
Соответственно, чисто теоретически
Если камера движется или не идеально зафиксирована, то по контрольным точкам понятно на сколько куда она продвинулась и можно соответственно скорректировать. Она же не может частично двигаться.
Если появляется лишний свет/блик/тень, то это влияет на все точки в области и так же можно скорректировать. Свет же не может отразиться только 1 точке, по идее он отразиться на всём изображении так или иначе…
совсем непонятна.
Первый — это Objective-C, как он может отставать от C# — на два десятка лет, если C# всего 14 лет?
Это подразумевается, что он старее? Типо старьё ))) Или что он с тех пор не развивался, а только в недавнее время стал развиваться?
Я C# к сожалению профессионально не занимался, но когда на курсах изучал, нам там прямо сказали, C# полностью всё ворует у Java и учиться на чужих, то есть java вских ошибках… Не знаю на сколько это имеет место быть, показалось достаточно забавным…
Для тех, кто в танке… В каком смысле «отставал»? Второму же всего чуть больше 20 лет ))) Как же «первый может отставать», он что только что появился? ))))…
В пользу второго можно сказать, что ко второму постоянно придумывают новые framework-и, которые сильно облегчают жизнь… Это не столько развитие общей структуры кода, сколько чисто заточенные вещи под мобильные устройства и не только устройства…
Я просто не знаю, что в этом плане может нам предложить «первый» ))).
При создании коммерческого ПО сейчас используются обфускаторы или сейчас все пошли на open source? Как они совмещаются с динамическим мета программированием? Можно часть кода оставить «чистым», а часть обфускарнуть?
Извините, если не по теме…
По сравнению с
gitHub.
Только пока не знаю как русский шрифт подключить.
Изучаю. Как получится подключить — дам ссылку, отсюда всю простыню заменю.
Там же ещё сделал небольшие исправление — что то вроде наследования для всех примитивов.
Добавил немного комментариев.
По поводу сферы, у меня был внутренний восторг, потому что на самом деле не мог предположить, что так всё легко и просто… Про себя чертил там соединял как то вершины, пытался найти какую то мнимую зависимость, а тут всё так легко и просто… Но я не знаю, как этот алгоритм подробнее расписать.
А в коде той же сферы, большая часть — это очень вспомогательная часть, которая только помогает построить…
Но не представляет из себя интерес в плане самого решения. Например, создание копии объекта, соединение разных прямоугольников друг над другом, расчет угла на который надо поворачивать и кол-ва итераций — это всё необходимо, но это не имеет смысл расписывать.
И напоследок, я внутренне очень сильно уверен, что если вы возьметесь реализовывать даже тот алгоритм построения сферы, который я дал, у вас реализация и в коде и просто алгоритмом будет намного лучше…
Я у своей сферы нашел один небольшой недостаток — 2 прямоугольника, назовём их условно юг и север множатся n-раз, где n — это 360 / кол-во прямоугольников… Или около того ))).
gitHub…
Спасибо, буду использовать.
P.S. На самом деле вся критика очень конструктивная. Мне кажется, что тяжело было не выругаться сильнее.
P.S.S. Если развивать данную идею, то можно создавать «скелеты», то есть просто расчет вершин через 1 точку центра… Мне остается в коде контролировать только центры. Таким образом облегчается задача создания зависимостей между центрами и построения того же самого «человека»…
habrahabr.ru/post/227415/ — это третья статья, пока финальная.
Дальнейшее развитие — это прежде всего работа над ошибками. И всё остальное уже прийдёт после того, как чуть больше изучу тему webgl.
Если абстрагироваться от ошибок, финальной частью данной серии я бы поставил — размещение объектов на карте. Как самый первый вариант реализации, который приходит в голову — это выбор примитива (описаны в 3-ей статье), может через список, может через кнопку — ввод минимальных данных (размеры, радиус) и размещение на карте — canvas 2d…
Я чувствую меня тут повесят ))) Но зная про матрицу проекции, я бы при перемещении по карте при повороте персонажа — разворачивал бы всю карту, ну на самом деле этот вариант кажется самым простым, только не самым производительным ))). Не буду я так делать, честное слово!
«последовательность точек, примитивов и прочей геометрии» у меня тоже рассчитывается через матрицу, а не вбивается вручную ))). Загвоздка как раз была в этом.
Как идея, чтобы учесть общие замечания. по сколько они сводятся к одному… Это найти способ описать инструкцию формирования примитивов по минимальному кол-ву параметров через данные которые можно передать в шейдеры.
Как самый «топорный» вариант я могу пользоваться своим алгоритмом, чтобы сохранить «последовательность точек, приметивов и прочей геометрии» где-нибудь а потом от кудо-нибудь это всё использовать.
При обрисовки сферы, правда с очень хорошей детализацией (то есть её можно без сильной потери уменьшить в полтора раза) у меня в массив индексов попадает 7200 значений, уменьшив их будет 5000, среди них около 600 (это я очень грубо) лишних, ну это я оставляю для тех, кому интересно найти ошибку в алгоритме сферы…
4400 точек… Ну сам я их буду вбивать…
А так
И она никак не закрыта от GLSL, если надо её перемещать, поворачивать использую все прелести большого кол-ва ядер GPU — никаких проблем…
У меня просто эта сфера и на JS не то что летает, это какой то сумашедший шарик…
Пока для теста использую requestAnimationFrame
Так вот он только на первых 10 секундах плавно, а потом…
rotateByX, rotateByY и rotateByZ — Я эти методы добавлю в примитивы.
Пока у меня у примитива
есть методы
rotateAroundCenter, rotateAroundPoint, rotateAroundMaxPoint, rotateAroundMinPoint, мне просто пока как то так легче, чем если сделать
rotateAroundCenterByX, rotateAroundCenterByY, rotateAroundCenterByZ, rotateAroundPointByX, rotateAroundPointByY, rotateAroundPointByZ,…
Можно, конечно оставить просто rotateAroundPoint и для него сделать эти приставки, но я старался вводить минимум координат. Как мне кажется, система вообще не должна от них зависеть.
По поводу идеальной матрицы…
Я пока до конца не понял.
Подумаю. Мне пока, пока я не дошел до «карты» и «общего мира» не требовалась матрица проекции. Скорее всего при дальнейшей работе столкнусь с данной проблемой, буду иметь виду это замечание.
Спасибо.
Я использую данную матрицу не только для перемещения объекта, но и для первичного подсчета координат объекта. В дальнейшем нет никаких затруднений данную матрицу совмещать с GLSL механизмами, так как по мимо всего прочего у матрицы остается — .source.
В остальном прошу прощения и спасибо за критику. Меня сподвигло написать серию статей приблизительно следующее:
В «стандартном уроке» от сплошного кода автор начал делить на функции, я решил чуть чуть развить тему упрощения.
Воодушевленный успехом, а особенно когда получился примитив — сфера (я не думал, что он так легко и быстро получится), я решил поделиться простой мыслью.
Холст — примитив — совершаем операции — добавляем — рисуем.
И на каждом из этих этапов — используем только необходимый минимум входных параметров.
Весь код — это возможно грубая, но просто «черновая» реализация данной идеи.
Это не то, что я должен каждый раз лесть во внутренний механизм webgl, если хочу добавить какой-нибудь объект.
В дальнейшем естественно буду улучшать — с учетом критики в этой и предыдущей статье, а также по мере изучения webgl.
Основная задача была сделать инструмент, в котором при минимальном описании можно было создавать 3d объекты… Это то, что в последней статье выдвинуто в функцию windows.onload.
А что может быть легче?
На будущее остается только создать инструмент, чтобы располагать примитив на карте, а не вбивать координаты.
Внутренняя реализация возможно не самая лучшая ))).
1.attributeSetup — данный метод — «заточка» на будущее, если вдруг мне надо будет подвязать атрибут при этом ничего не меняя или сделав минимум изменений в самом Scene. Пока я этот метод не вызываю.
2. enableVertexAttribArray по поводу attributeSetup уже написал, по поводу initProgram — обшибся… Я ещё добавлял буфер с матрицей раскраски, из «стандартного урока»… Забыл убрать. На самом деле, пока не знаю, как лучше добавить атрибуты.
3. Осталось от отладки. Исправлю.
4. А я не знал, что это выкрутасы ))).
По поводу самого вопроса «есть ли возможность» — речь идет о загрузки дополнительных вершин… Я понимаю, что есть STATIC_DRAW, есть и другие способы и обойтись можно 1 буфером.
Как я понял по вашему комменту способ всегда был и есть. Меня просто немного смутило
«When a buffer is bound to a target, the previously bound buffer for that target is automatically unbound.».