Embedding the script language into optical simulation software

Deryabin, N. B.; Zhdanov, Dmitry; Sokolov, V. G.

doi:10.1134/s0361768817010029

Cited by 12 publications

(2 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Поддержка языка сценариев Python в нашей системе оптического моделирования реализуется в виде отдельной библиотеки, содержащей интерпретатор этого языка, который взаимодействует с остальной системой, через унифицированный целевой интерфейс. Набор объектов, образующих C++ API нашего оптического комплекса естественным образом переносится на язык Python с помощью специального пакета CPython [6]. Получившийся в итоге интерфейс программирования сценариев (Python API) использует ту же самую иерархию объектов, что и комплекс оптического моделирования и, что самое главное, позволяет осуществлять доступ из сценариев к объектам системы, их свойствам и методам с помощью обычной точечной нотации.…”

Section: интерпретатор Python скриптовunclassified

Usage of Scenario Based Modeling Automation in Optics CAD Systems

Kopylov¹

2022

Proceedings of the 32nd International Conference on Computer Graphics and Vision

View full text Add to dashboard Cite

This article describes approaches to the use of scenarios in the automation of applied tasks within the framework of working with a software complex of optical modeling and photorealistic computer graphics. Optical modeling complex should include support for scripting, since conventional tools, such as those provided using a graphical user interface, are usually not enough to perform a variety of tasks that arise in practice. A brief overview of existing solutions is made. Methods are proposed that ensure effective bringing of scenario support into an existing optical modeling system. These methods provide full access from scripts to system modules, including computational modules, various simulator modules, etc. Both trivial scripts containing ordinary command sequences and more complex ones using the capabilities of high-level scripting languages such as Python are supported. Separately, a special high-level API is considered which is used for the interaction between of scripts written in the Python language and the optical modeling system. This API can also be used to extend the capabilities of the system with new parametric objects. The specialized software modules integrated into the optical modeling system, such as the batch interpreter, script interpreter and editor, extension class editor, are considered in detail. Examples of scenario-based modeling automation are given.

show abstract

Section: интерпретатор Python скриптовunclassified

Usage of Scenario Based Modeling Automation in Optics CAD Systems

Kopylov¹

2022

Proceedings of the 32nd International Conference on Computer Graphics and Vision

View full text Add to dashboard Cite

show abstract

“…Their main disadvantages are high complexity, high development cost and obstructed debugging. In any case, exist-ing solutions uses CPU: RSL [7], OSL [27], VEX [22] and other [4]. Although, Octane GPU renderer implements a subset of OSL for procedural textures [26].…”

Section: Domain Specific Languagesmentioning

confidence: 99%

Restricted Extensions for GPU Photo-realistic Renderer

Sanzharov¹,

Frolov²,

Pavlov³

2019

GraphiCon'2019 Proceedings. Volume 2

View full text Add to dashboard Cite

Photo-realistic rendering systems on CPU traditionally have significant flexibility achieved mainly by the ability for end user to write custom plugins or shaders. The same cannot be said about majority of photo-realistic GPU renderers. Most «classic» approaches to design of user-extendable software on CPU, such as object-oriented plugins are not very well suited for GPU programming. In this paper we propose a restricted approach to developing extendable GPU rendering system at low development cost. Our hardware agnostic light-weight approach can be applied to existing rendering systems with minimal changes to them. We apply our approach to the problem of procedural textures implementation and show that, in addition to simplicity, our approach is faster then existing GPU solutions.

show abstract