GD Star Rating
loading...

Извините, что мы к вам обращаемся, простите за ламерские вопросы и все такое.

Мне нужно примерно следующее: обрабатывать локально сохраненные текстовые файлы, изменять структуру папок, вызывать кое-какие программы с командной строкой, динамически генерировать HTML со структурой файлов и управляющими кнопками.

Причем, желательно, чтобы для этих целей не нужно было ставить сервер, SQL и прочая. Чтобы все было как можно более просто.

Вопрос в том, на чем стоит это все писать, если опыта нет совсем, а сделать нужно как можно более быстро.

Админы и сочувствующие посетители hardblog.net посчитали злободневным:модные штуки

28 Responses to Извините, что мы к вам обращаемся, простите за ламерские вопросы и все такое.

  1. Ruhed:

    да, забыл сказать, что все под виндовс.

  2. 0duaTa:

    : тебе задачу вот так и поставили, как ты ее тут описал? меня умиляют люди, просящие помощи, при этом пытаясь скрыть максимум полезной информации.

    Что касается ответа на твой вопрос: C#, Python.

  3. Ruhed:

    : ну, задачу я сам себе ставил, это должно быть решение, которое позволяла бы управлять большими 3д-проектами. Т.е. возможность быстро поменять версию геометрии, текстры и тому подобное. Я не стал детали расписывать, но суть сводится к банальной обработке файлов и построении дерева объектов и управляющих кнопок в окошке бразуера.

  4. Relbad:

    : Как это все связано с динамическим генерированием html? Зачем тебе веб?

  5. Ruhed:

    : ну, таково было пожелание заказчика. Я бы тоже лучше это в виде простейшей standalone программы сделал бы.

  6. Relbad:

    : ну, задачу я сам себе ставил
    То есть задачу все-таки не ты ставил?
    Пиши подробности, что за 3д-проекты, что за софт, какая все-таки полная постановка задачи, иначе тебе вряд ли кто-то поможет.

  7. Ruhed:

    : ок! Дело в следующем: фирма, в которой я работаю, занимается визулизацией автомобилей. До недавнего времени каждая модель была в виде отдельного проекта: геометрия, текстуры, материалы и т.д. в одной директории с поддиректориями. Проблемы начинаются тогда, когда один элемент должен принадлежать двум разным моделям. С одной стороны можно сохранять его локально в каждом проекте, с другой стороны можно сделать библиотеку общих элементов. Первое не подходит, так как, изменив геометрию в одном проекте, она не проапдейтится автоматически в другом. Второе не подходит, потому что превратит проекты в одну большую свалку геометрии, текстур и материалов.

    Поэтому появилась идея сделать что-то вроде виртуальной структуры для каждого проекта, в которой бы стояли ссылки на актуальную версию каждой детали. Таким образом можно быстро поменять версию геометрии, сделать бекап всего проекта, быстро генерировать разные версии (детальная триангулизация, грубая и т.д.).

    С другой стороны шеф не хочет, чтобы все было чересчур виртуализировано (никаких mySQL, баз данных и т.д.), мол, если вдруг чего поломается, чтобы можно было руками поправить. Поэтому я хочу сделать что-то вроде placeholder-ов – маленьких ascii-файлов там, где геометрия не является уникальной (скажем, общая деталь для двух автомобилей), а также ссылки на старые версии.

    Еще одно условие было, что все это должно иметь веб-интерфес, т.е. запускаться в браузере.

    Надеюсь, понятно описал

  8. Yzzmo:

    : hg/git/svn не подойдет?

  9. Ruhed:

    : знать бы еще, что это такое!

  10. Ruhed:

    : а под винду оно работает?

  11. Ruhed:

    : а, работает)

  12. Axoon:

    : чтобы все было чересчур виртуализировано (никаких mySQL, баз данных и т.д.), мол, если вдруг чего поломается, чтобы можно было руками поправить.

    Это пять. Сервера баз данных на самом деле только для того и нужны, чтобы, если сломается, то нельзя будет уже руками всё исправить. В них даже специально вносятся модули, которые препятствуют контролю целостности данных и возможности их резервного копирования.

  13. Drasuper:

    : сайт-визитку делаете?

  14. Ruhed:

    : у нас немного другая специфика. Если бы все зависело бы только от меня, я бы сделал базу данных. Но пока так, как я описал.

  15. Ruhed:

    : нет, я выше описал, для чего это нужно.

  16. Drasuper:

    : я красненьким забыл сделать

  17. Relbad:

    > Проблемы начинаются тогда, когда один элемент должен принадлежать двум разным моделям.
    Это все на одном сервере? Тогда самый простой вариант – действительно с симлинками. То есть создаешь директорию “shared” с красивой структурой под все шаренные объекты и сваливаешь их туда. В самих же проектах линкуешь объекты на shared-папку. Вообще сложностей не вижу.

    > Второе не подходит, потому что превратит проекты в одну большую свалку геометрии, текстур и материалов.
    Что?! Нихуя не понял

    > Поэтому появилась идея сделать что–то вроде виртуальной структуры для каждого проекта, в которой бы стояли ссылки на актуальную версию каждой детали. Таким образом можно быстро поменять версию геометрии, сделать бекап всего проекта, быстро генерировать разные версии (детальная триангулизация, грубая и т.д.).
    Теперь вообще все в куче – версионирование, бекапы. Это тоже является задачей, или ты сам выдумал? Как это все вообще соотносится с элементами, принадлежащими нескольким моделям?

  18. Relbad:

    : Если хочешь дальнейшего диалога, то показывай структуру проектов, показывай, какие элементы в них являются общими и между кем они общие – между проектами, или внутри одного проекта между некими моделями?
    А также поясняй момент с необходимостью версионирования и бекапами.

  19. Ruhed:

    : диалога хочу! Вот, собственно, те проблемы, которые необходимо решить (можно я в виде картинок?):

    размер 500x346, 32.39 kb

  20. Ruhed:

    : черт, картинки мелкие получаются. Тогда текстом:

    Problems:

    Uniqueness of the actual state of the parts and the shaders (materials)
    Cross-references of the same parts in different models (objects)
    History and backup (possibility of restoring of the preview state of models or parts by date, version or addition conditions)
    Support of multi-version representation of the models (LODs, versions, different materials, texture’s resolutions, etc.)
    Simple switch between setups for PVZ, Mentalray, Iray, Maxwell and so on
    Simple switch of level of details of the scene or scene’s parts
    Simple switch between material’s versions
    Simple switch between versions of the parts
    Separate multi-version for each leaf of the data tree in the scene
    Advanced data management (search requests through all the databank with conditions in regular expression language. For example:
    all parts that were modified after the certain date, in the certain project
    all materials were used in the certain project.
    all versions of the certain part.
    Vertical versions-graph for different versions of the parts. For each part of non-zero level there are one or more parents on preview level. Also for each part of non-last level there are one or more children on the next level. Also each version of the part has separate material definition, LOD’s, proxies and so on). This is important since in different version there could be different number of the parts that represents the same object.

    Possibility of the packing all dependencies in one project (for example: only the textures that relate to the certain project) for transfer or archive the data
    Transparent data storage through hierarchy of directories for unique parts and paceholders for common parts (LED?s, lamps, common objects, etc.)
    Batch actions for all elements of the project (changing texture resolution`s and formats, alternation materials and geometry)
    Automatically creating proxies, mi-files and LODs.
    Automatically scene-hierarchy generation (respectively to the names of the parts)
    Render and modelling-software (Maya, Catia, Icem Surf, DeltaGen) independency
    Minimization of human errors
    Minimization time of data administration and management.
    Easy integration in another solutions (calendar and appointment software)
    Easy monitoring of actual state of the project
    Presets for on-the-fly scene generation
    Remote access through web-interface (if needed)

    Простите мой безграмотный английский

  21. Ruhed:

    : ну, бекапы это, так сказать, побочная тема. В основном все служит для следующей цели: для разных целей нужны разные настройки сцены, разная детализация геометрии, разные материалы и разные версии данных. Идея была в том, чтобы собирать сцену, так сказать, на лету, из уже готовых запчастей. На самом деле в большинстве 3д-пакетов это все уже реализовано через референсы. Да только заказчик хочет решение не зависящее от конкретной 3д-программы. Поэтому и некая нелогичность.

  22. Relbad:

    : То есть вы хотите реализовать кусочек функционала всяких Maya и 3dMax в веб-приложении, да еще при этом не имея опыта программирования? 🙂 Вдвойне глупо.
    В чем цель, зачем абстрагироваться от заточенных под графику программ, если они именно для этого созданы и писать кривое поделие?
    Я прочитал все, что написано выше, но понял конечно далеко не на вашем уровне. И опять же связать с изначальной постановкой задачи мне это сложно.
    Попробуем пройтись по пунктам:

    Problems:

    Uniqueness of the actual state of the parts and the shaders (materials)
    Не ясна суть проблемы

    Cross–references of the same parts in different models (objects)
    Если один сервер, то самое простое и логичное решение – общая shared-директория, на которую линки из моделей. Если несколько серверов, то общее сетевое хранилище, либо другие варианты в зависимости от конкретных целей.

    History and backup (possibility of restoring of the preview state of models or parts by date, version or addition conditions)
    History: используйте git для хранения всех текстовых файлов, получите одну из самых распространенных современных систем котроля версий, по поводу графики – it depends, надо думать, стоит ли ее хранить в git.
    Backup: у вас ведь windows? Напишите/нагуглите пару элементарных bat-ников, копируйте с нужной частотой целиком проекты, если вам это позволяют ресурсы. Не начинайте сразу со сложных способов, возможно вам подойдет самый простой, он же будет самым надежным.

    Support of multi–version representation of the models (LODs, versions, different materials, texture’s resolutions, etc.)
    Для меня непонятно

    Simple switch between setups for PVZ, Mentalray, Iray, Maxwell and so on
    Аналогично

    Simple switch of level of details of the scene or scene’s parts
    Аналогично

    Simple switch between material’s versions
    Все свичи делать одним батником, меняющим ссылки – просто и надежно.

    Simple switch between versions of the parts
    Аналогично

    Separate multi–version for each leaf of the data tree in the scene
    Непонятно

    Advanced data management (search requests through all the databank with conditions in regular expression language. For example:
    all parts that were modified after the certain date, in the certain project
    all materials were used in the certain project.
    all versions of the certain part.
    Ой блять, он вам много платит надеюсь? Тут стоит узнать, насколько ему это надо, это уже тянет на какую-то БД со всеми частями проектов, поиском, продумывать надо.

    Vertical versions–graph for different versions of the parts. For each part of non–zero level there are one or more parents on preview level. Also for each part of non–last level there are one or more children on the next level. Also each version of the part has separate material definition, LOD’s, proxies and so on). This is important since in different version there could be different number of the parts that represents the same object.
    Ничего не понял

    Possibility of the packing all dependencies in one project (for example: only the textures that relate to the certain project) for transfer or archive the data
    Выкачать по линкам все зависимости для проекта и запаковать его – также батник написать, не проблема.

    Transparent data storage through hierarchy of directories for unique parts and paceholders for common parts (LED?s, lamps, common objects, etc.)
    Что я и говорил – одна или много shared-директорий, в проектах тоже все структуры аналогичные желательно делать. Проект хранить в гите. в каждом проекте линки и зависимости на shared-директорию.

    Batch actions for all elements of the project (changing texture resolution`s and formats, alternation materials and geometry)
    Хз

    Automatically creating proxies, mi–files and LODs.
    Хз

    Automatically scene–hierarchy generation (respectively to the names of the parts)
    Хз

    Render and modelling–software (Maya, Catia, Icem Surf, DeltaGen) independency
    Насколько я знаю, это дорогого стоит, независимость от платформ.

    Minimization of human errors
    Убить всех хьюманов, оставить только роботов

    Minimization time of data administration and management.
    Аналогично

    Easy integration in another solutions (calendar and appointment software)
    Это вообще планы все на сколько лет и какую команду?

    Easy monitoring of actual state of the project
    Git+collaboration system(basecamp, например)

    Presets for on–the–fly scene generation
    Хз

    Remote access through web–interface (if needed)
    Ко всему выше описанному? Really? Нахуя? Выясни обязательно и постарайся отмазаться от всех сложностей и веба в том числе, только время потеряете, если этому нет твердого обоснования.

  23. Relbad:

    : Вообще для всего этого дела точно должны быть дорогие монстры из Enterprise-мира, один из которых возможно вам подойдет, гуглите.

  24. Erobad:

    Используй apache ant http://ant.apache.org/bindownload.cgi
    Для генерации HTML можешь заюзать какой-нибудь C#, python или что-нибудь о чем имеешь представление

  25. Ruhed:

    : ну, есть, например такая замечательная программа как AlianBrain, заточенная как раз под анимационные проекты. Но шеф посчитал, что она чересчур сложная и все такое.

  26. Ruhed:

    : Привет еще раз! Удалось убедить шефа, что все это можно для начала сделать без web-интерфейса. Т.е. подойдет, в общем, любой язык)

  27. Ruhed:

    : спасибо за подробный! Мне самому некоторые опции не кажутся необходимыми. Ну и еще проблема в том, что опыта в программировании у меня немного, и он довольно специфичный: писал я, в основном скрипты для 3д-программ и расширения для рендереров.

Добавить комментарий