Space engineers как вывести изображение с камеры на экран

Обновлено: 05.07.2024

I'm pretty sure I'm not the first person to suggest this, so sorry in advance if it is redundant and the answer has already been provided.

What I am suggesting today is a way for camera to link its feed to a the screen, whether it be an LCD panel, control station, or flight seat. That way, it'd allow for features such as a security room where it's full of screens displaying surveillance footage or - what I see as most important - pilot the ship without having to access the camera every time through the UI, as all the footage is already being displayed on the screen (as long as there is power, of course). And if that can be done, it could be extended to the smaller screens in the cockpit so we could have something like a weapons camera. Feedbacks welcome!

Comments ( 21 )

It might be done, there is already a mod for that (IIRC it does not work anymore).

But it will decrease the performance of the game - you need to have powerful GPU for that, as each screen is essentially another frame to render. Thus if your FPS is 40, with another camera-on-screen it might drop to 20 (if low FPS was caused by taxed GPU, not overloaded CPU). And it will incur some cost in CPU performance.

But it can be managed: in graphic settings there might be another slider: maximum of camera-to-screens, max distance of player to screen with screens nearer to player taking preference, plus if screen is LOD model it should be ignored.

Two screens showing the input of one camera shouldn't incur double GPU cost - camera should render to buffer and that should be used twice.

And camera displaying screen (with input from any camera) should either show blank screen or screen from frame behind.

The original mod worked fine, almost no performance impact whatsoever. It was well designed, didn't do anything it didn't need to, and used a dynamic pool of your available frames so that it literally couldn't drag your FPS down. The worse your frames, the less the mod did. If you got over 60, it used those for even smoother displays. Xocliw showed it off on the community stream. He showed it directly to Marek, showed it working beautifully, while having none of the drawbacks it was claimed such a mod would have. And then Keen ignored the potential and changed a bunch of things and the mod died.

It did have the drawbacks it was claimed such a mod would have. it's just, it was showcased on powerful computers with enough frames to spare. The second you don't have a powerful computer, you'll see the drawbacks quickly. This is why it wasn't made vanilla.

I dearly wish this wasn't the case because that mod was really cool. but it can't work as anything else than a mod.

Again with the 'can't be done'. I'm reminded of that quote regarding senior scientists saying something can't be done and being most certainly wrong.

Duke Nukem 3d had a camera view to screen feature in a game with user generated maps/layouts 22 years ago. Granted it wasn't 1080p but I don't think anyones expecting that from a Text panel. Unpossible!

From what I can see in the Steam and Keen forums, this mod wouldn't be difficult to implement but suffers greatly from a performance drain. This could be mitigated with a slider on the link controlling frames per second for a capture rate.

Most notably, this would be an excellent feature for Experimental Mode (now that we have it).

And also without memory serialization of objects .

glad to see this thread bumped i find it ridiculous that this isn't already in the game. Surely you could implement this with some sort of anti-rastorization method where you just don't render the parts of the ship eclipsed by the display just like if you gave dirt or whatever a transparent texture back in minceraft, that's how rodina does it; and even without the fact that this method would be way more efficient, you would also end up with a better, more spacey, implementation 'cause it would have perspective.

@Burstar: from my side that was no excuse, that was explanation.

If different programming tools and approach would be used, game engine would be more effective . but the development would be slower .

One thing that would help the framerate is to have the LCD camera view be low framerate itself such as 5 to 20 fps

I was going to sugest the same thingh, glad i searched it first.

If we have cameras and we have LCD panels its only natural to conect the 2.

About the Duke Nukem 3d thing, are you talking about seeing yourself in the bathroom mirror? Because that's actually fake. It's a duplicated room and player model that is displayed with clever rendering tricks.

It's a fantastic feature that i'd love to have, with current technology (Not just SE), it's just not really possible in a way that would be usable in game.

@Domingo yeah I see that now. Apologies I read it wrong :P

@zooltan no, the camera monitors would show a display of the camera view after you look through it. Its framerate was like 1Hz and it only lasted for so long but considering I was playing it on a x486 (I think).

An option in game settings with sliders to limit darn thing. Probably I would think of getting new computer since cam feedback was so cool back in a day. But I guess it's to much of an effort, shame mod isn't working anymore.

But what if i just REALLY REALLY wanted to build myself a gundam?

To help, you can add this feature BUT calculated only in local when people are near the grid. So it wont use/overload net datas ?

Old mod was great, as long as you didn't have dozens of screens running. IIRC there was a 'performance' slider to make it more user friendly to lower spec machines. If you could at least consider it Keen, that would be great!

While the actual rendering is client side, the camera can be several subgrids - maybe kilometers - away and see a different part of the universe. A camera would be like an additional player, spawning in local asteroids and streaming grid data from the server to be rendered on the remote camera feed. Or cameras are 100% local and intended for cameras in close proximity only, with no load on the server and very low PCU amount. (Maybe have separate server/client PCU?)

Eventually all "extra rendering step" could be queued up so that only one extra rendering is done per frame. I.e. environment cube maps could be on every frame if the queue is unused, but reduce to every second frame if camera feeds are active:

(Effective frame rate of the three cameras would then be 10 FPS. Camera feeds should only update when the player is actually standing in front of and looking in their direction. Screens being "freshly" activated would take the next slot in the update queue for a max 1 frame delay, unless several screens activated in the same frame.)

Not sure about random LCDs, but I definitely would like to have a feed from camera in my cockpit.

Hooo Yes !! make that !

THis is the first fing I was so disapointed when building my first ship in SE :

I saw Camera, LCD, then it was obvious I could link a camera feed to one of cockpit LCD to have a view. even at low resolution, and even with limitation numbers.

Yes please do that for external LCDs or cockpit LCDs even for one or two feeds that would be awesome.

not mine but just wanted to post it here

i saw this reddit post the other day but it takes a big performance hit.

Keen Support replied to this in an XBox thread;

Saying that "they will consider this feature" .

This current page for PC, was posted way earlier than that post yet, they didn't reply to this one.

Other than possible incapability due to technical difficulties, I really don't understand why developers disregard highly requested features like this and push out totally unrelated content for long periods of time.

In short, as many people out there, I really believe that this should've been in the vanilla game since the LCD's were introduced and also believe that it would elevate the game play so much.

Having the ability to view a camera image from an LCD in a basement - which is what I nearly always end up building in order to protect my gear from meteorites - would be a massive boon.

Also, displaying multiple camera images on LCDs means that a ship could have a decent bridge buried deep inside it and still have good visibility of the surrounding space, without needing to cycle through cameras while sitting in a control seat.

I like the security room concept, too.

A few other suggestions would be to resize the screen if adjacent displays share a tag, an option of linking it to a remote grid would be useful too for situational awareness of your current position while controlling a remote vessel.

The mod is smart about it and makes it so that the LCD can "share" frames instead. So it can update at 30 fps but it doubles the GPU Render Load, or all the way down to 1fps which divides evenly amongst other LCDs. So if you had the setting at 30fps they'd each run at 15fps, which would divide further as you added more.

It's kinda strange to have jump drives and gravity generators but a simple backup camera is too much.

I don't know the limitations of this engine, but that what we ask for here, is used in many games like Portel or Prey (the old one) and is used, when some NPCs are in a monitor. For example, in Half Life 2, when Wallace Breen has his speeches on the monitors, the actual NPC is loaded in a separate room on the map, where the NPC gets recorded by a virtual camerajand is streamed directly to the ingame TVs and monitors, the player can see and they do it that way, because, according to the devs, tihs is much easier then make a actual video clip to play back on the screens. So it schouldn't be wichcraft to make something like that. Except the engine really can't cope with that.

The Mods we had, are more or less a collection of workarounds to make this feature somewhat functioning, but someone with unrestricted access to the source code, should be able to implement, at least the frame work, for such a function, without all too heavy performance impacts. Furthermore we are in an age, of ridiculously powerfull GPU like the Nvidia 30 Series and Space Engineers never was a casual game, requirement wise. And for those with a too weak system, we could make a tab in the world settings to disable this feature.

The examples you use, only have a few limited "Cameras" active at the same time, and several of those probably uses a different technique (Like a simple pre-rendered video for the speech)

The problem is, no matter the engine, rendering an extra camera will always cost a full extra render pass; which will scale for every camera you have active.

It's not a matter of it being hard to implement the camera rendering to a texture. That's easy. It's about the rendering cost of doing it.

So the only way it can work, without tanking the FPS completely, would be to limit the number of cameras that can be active, to maybe 1-3, which I don't thing is what the players want.

The rendering load could be alleviated by defaulting to a low-refresh camera mode where the camera only updates at, for example, 15 fps or lower and an optional high-performance mode where the camera updates like the player camera.

i would make lcd refresh rate based on distance to closest player, that is looking at that lcd - so game would crank up lcd fps only when someone is actually looking at it and 'freeze' display when nobody is around or looking on something else .

I also find it very strange that this is so hard to implement. Duke Nukem 3D dynamically rendered security cameras onto display screens just fine 25 years ago ( before even basic 3d graphics cards were even in most gamer's PCs ) along with a few N64 games, like Goldeneye. Not to mention more recent games like Half Life 2. There are a lot of ways to keep it performant on modern systems. Here's a few suggestions that little old me can think of to keep system performance from being too negatively impacted.

If a remote camera LCD isn't in visible range to a player, then don't gather render data from the camera nor render the camera onto the LCD. I do not believe this is something that a modder could do, since it would require access to a player's rendering data and being able to detect if any remote camera LCDs are within what's being rendered.
Any camera feeds are sampled at a lower resolution and also rendered to LCDs at a lower resolution than when a player views through the camera directly. With a lower resolution on both sampling and rendering I would expect GPU stress to be lower as well.
Nested camera LCDs ( any LCD's rendering a camera that are THEN viewed by a later camera and rendered to a later LCD ) would be only rendered at 1fps and only when the player is looking at the later LCD, otherwise it is not rendered. Or just don't render nested camera LCDs at all, though that might confuse some players if done without explanation.
Restrict FPS and change resolution based on system specs, which could be checked on initial game load.

Many games implement in-view screens of the game world. This isn't new and not impossible just something Keen chose not to implement with their time. Other priorities. The LCD displays in the game and the cameras seem like a perfect match.

Ill be honest, I don't care about the GPU limitations and all the technical issues. Sorry but thats not for us players to worry about, we come up with ideas and devs make the judgements and solutions. If this feature works it would be a massive improvement to the game.

Honestly I love this idea and I wish it was in the game this would be definitely revolutionary in my opinion and I think it would definitely be a great idea!

And it could be quite low resolution, we would not need 4 K resolution ;)

And if that is a problem, limit how many feeds you can send over radio and only update screens within player visibility.

You could even have lower frame rate, or have fram rate being dependent on distance to closes player so screens further away only update 10-20 fps and close by screens at higher rate.

Мод "CameraLCD [Plugin]" для Space Engineers

Мод "CameraLCD [Plugin]" для Space Engineers добавляет Плагин, позволяющий ЖК-дисплеям отображать прямую трансляцию с камер.

Для работы этого мода требуется клиентский плагин SEPluginManager .
Для бесперебойной работы требуются хорошие характеристики ПК и / или уменьшенные графические настройки. Ожидайте снижения производительности и FPS. Может вызвать сбои. Вероятно, сломается, когда Кин обновит игру.
У камер есть несколько параметров, которые можно настроить с помощью пользовательских данных. -fov, -диапазон, -контраст, -яркость. При их использовании вы должны использовать -name и имя должно быть заключено в кавычки.

Поместите камеру и ЖК-экран на одну сетку (через разъемы тоже можно). Найдите ЖК-дисплей в терминале и установите для Content значение «Script», а для Script - «Camera Display». Отредактируйте пользовательские данные и введите точное имя камеры, которую вы хотите отобразить.

Информация о файле

Загрузил: karazupa
Автор: Xo
Формат файла: ZIP
Размер файла: 0.8 mb
Источник: Перейти

Вы можете войти в свой аккаунт или зарегистрироваться на сайте, чтобы скачивать моды без ожидания.

Space engineers как вывести изображение с камеры на экран

Но опишу его же действия на нашем сервере на своем личном примере.

Самый простой вариант:

Также можно указать например кол-во водорода в танках - Tanks * Hydrogen. И многое другое.

Space engineers как вывести изображение с камеры на экран

Скрипт для посадки на планеты.
Аля "Остановить поршень когда посадочное шасси зацепится за астероид"
================================================================
void Main(string argument)
IMyPistonBase LandingPiston = GridTerminalSystem.GetBlockWithName("LandingPistonName") as IMyPistonBase;
IMyLandingGear LandingGear = GridTerminalSystem.GetBlockWithName("LandingGearName") as IMyLandingGear;

if(LandingGear.IsLocked)
LandingPiston.GetActionWithName("ResetVelocity").Apply(LandingPiston);
LandingPiston.GetActionWithName("IncreaseVelocity").Apply(LandingPiston);;
>

КАК заставить это работать:

LandingPistonName и LandingGearName это названия в панели управления (в терминале) поршня и шасси соответственно. Желательно использовать англ.язык и названия без пробелов. К примеру: LandPiston_1; Gear2 и т.п. Я не ручаюсь за работу с кирилицей)
Это все, что вам нужно заменить в скрипте.

Далее таймер: выставляем задержку таймера в 1 секунду (на минимум), ставим в Setup Action запуск отчета таймера и Run программируемого блока.

ОЧЕНЬ ВАЖНО: главное правильно поставить соответствия между программируемым блоком, поршнем и шасси. Ибо может выйти так: "когда шасси1 закреплено остановить поршень2" - сами понимаете такой вариант не катит никаким образом))

p.s. в воркшоп выставлю позже, когда будет готов прототип и видеодемонстрация.

Для работы ЛЮБОГО количества шлюзов требуется ОДИН программируемый блок.

Отображение провреждённых/недостоенных блоков.
Само собой автоматическое :)

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

p.s.
Обращайте внимание - если включить в основную группу ВНЕШНИЕ двери то после стабилизации давления они откроются :D будьте внимательны.

Невероятно полезный скрипт, который позволяет с помощью одного нажатия кнопки выбрать положение ротора или поршня. За подробностями смотрите видео по ссылке.

Скрипт предназначен для ведения огня очередями, для этого он попеременно отключает заряженные орудия - здорово повышает огневую мощь и удобство стрельбы. Поддерживает автоматизацию огня. Автор не я.

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

Переименовываете все орудия одинаково, к примеру "Пушка", без номеров и всего остального.

Загружаете в прогблок скрипт, меняете значение GUN_NAME на "Пушка". Выставляете задержку стрельбы - значение TIME_STEP, чем больше, тем быстрее стреляет, для некоторых орудий максимальная указана в самом скрипте в комментариях, никогда не ставьте отрицательное значение и ноль. Поставите слишком большое значение TIME_STEP - скрипт будет работать быстрее, чем у орудий задержка между выстрелами, и они будут стрелять как попало. Компилируете и сохраняете.

Таймер переименовываете в "sequencerCycler", лампу переименовываете в "sequencerToggle". На таймере выставляете одно действие - запустить программируемый блок, задержку можно не трогать.

Запускаете прогблок. Включаете блок с именем "sequencerToggle".

Заряжаете орудия жмете на гашетку. Для автоматизации стрельбы просто соберите заскриптованные орудия в группу, и повесьте на горячую клавишу вкл/выкл стрельбы.

Если не все орудия заряжены полностью, то стрелять будет как попало.

При начале стрельбы бывает стреляет сразу из двух орудий.

Имена всех задействованных блоков можно менять в самом скрипте, таким образом можно сделать несколько групп орудий. Если "sequencerToggle" выключен, орудия будут стрелять как обычно - залпом.

Адам, не совсем мод - плагин, выводит изображения с камер и турелей на любые LCD

Простой скрипт, который на левый дисплей выводит предупреждения о повреждениях, заканчивающемся боезапасе и малом количестве ресурсов. На правый дисплей выводится содержимое всех хранилищ корабля. Центральный дисплей отображает визуальное предупреждение (картинкой).
Имеет возможность небольшой настройки под себя в самом начале скрипта, где необходимо будет прописать свои ЖК панели для работы скрипта. По-умолчанию стоит: ЖК панель слева, ЖК панель справа, ЖК панель центр

Работает на версии 01_171_003 без модов на пиратке.

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

Иван,
public void Main(string argument)
<
IMyOxygenTank hTank = GridTerminalSystem.GetBlockWithName("Hydrogen Tank") as IMyOxygenTank;
IMyTextPanel disp = GridTerminalSystem.GetBlockWithName("LCD 1") as IMyTextPanel;
disp.WritePublicText(hTank.GetOxygenLevel().ToString(), false); //заполненность бака
>
выдает значение float от 0 до 1, где 1 - полный бак

В программируемом блоке появилась возможность сохранять переменные.
Если заметили, по-умолчанию кроме Main() в редакторе появились две функции public Program() и public void Save().

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

Функция Save() так же автоматически запускается и сохраняет предоставленное строковое значение. Сохранение происходит не каждый запуск скрипта. Заметил, что сохраняется, когда открываю редактор программируемого блока или сохраняю игру, других триггеров для срабатывания этой функции я не обнаружил.

Если снести программируемый блок, построить другой и вставить туда идентичный код, сохранения не восстанавливаются.

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

Пример прикреплен ниже.

Может быть и не самый полезный , но прикольный =) Это музыкальный плеер. Проект старый, но оригинальный. Думаю Доп. информации не надо . Ссылка:

Описание: Скрипт подсчитывает содержимое инвентарей, перемещает позицию, которая не строится в конец очереди сборщика.
Умеет сортировать содержимое по контейнерам и дозаказывать компоненты в ассемблере на основании установленных лимитов.

Настройка:
в поле CustomData вносятся параметры для инициализации скрипта: (любая из строк может быть пустой и будет пропущена)

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

все последующие строки устанавливают настройки контейнеров, в формате МаскаПоискаКонтейнера:ЧтоВНемЛежит,ЧтоВНемЛежит
что лежит можно указывать частично, типы указываются со * сначала,
например: *контейнер:Строительный - будет складывать Строительный компонент в контейнеры, заканчивающиеся на «контейнер»
*готовая продукция*:*компон,*боепри - все компоненты и боеприпасы будут перемещены в контейнеры в названии которых встречается «готовая продукция»

При первом запуске скрипта инициализация производится автоматически, далее по команде.

Команды: Скрипт поддерживает команды с параметрами. Команда и параметр разделяются «:»

Доступные команды и параметры:
init:panel,limit,storage,reload
производит переинициализацию скрипта из CustomData программного блока, параметрами можно ограничивать что инициализировать
panel - заново ищет текстовые панелей
limit - ищет сборщик из которого берутся лимиты
storage - перенастройка контейнеров
reload - поиск и запись доступных ассемблеров и блоков в которых будет в дальнейшем происходит поиск

? - Выводит информацию о текущих ассемблерах, лимитам и тестовым панелям, с любым параметром также выведет все обслуживаемые блоки с инвентарями

limit:название ассемблера - добавляет к существующим, лимиты из ассемблера. без параметров - очищает все установленные ранее лимиты

>:МаскаПоискаКонтейнера:ЧтоВНемЛежит,ЧтоВНемЛежит
устанавливает отбор для сортировки элементов в контейнере. Если перед первым параметром добавить +, будут добавлены доступные элементы иначе заменены

mask:маска поиска блоков
Устанавливает маску которая применяется при поиске обрабатываемых инвентарей, если маска пустая строка обрабатываются все доступные инвентари

reload:bloc,ass
Находит и запоминает все ассемблеры и блоки в которых будет в дальнейшем происходить поиск. Параметрами можно ограничивать что нужно искать. Без параметров ищет все.
Unload:маска
Производит единоразовое перемещение элементов из блоков подходящих под маску в установленные контейнеры. Полезно при разгрузке бурового корабля.

Скрипт находит все блоки ассемблеров и инвентаре, а затем обходит эти списки. Поэтому если необходимо заново найти инвентари или ассемблеры вызовите команду reload. Если необходимо переинициализировать текстовые панели воспользуйтесь командой init. Это поможет при разрушении готовых или достройке новых блоков.

Все настройки скрипт сохраняет и восстанавливает автоматически, при перезагрузке ничего перенастраивать не нужно

Читайте также: