Jump to content

GDTF Forum

Petr Vanek

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Petr Vanek

  1. The data in the editor is being processed server side on the builder backend. Not necessarily stored permanently, but there is the shorttime period when this happens. Nobody is watching this data, but from technical perspective, the server is involved. At this point, there are discussions about how to make this better for manufacturers, but at the same time, we want to make sure that the free to use builder is also providing useful data back to users.
  2. Hi @David "Rex" Whalen, Can you perhaps post info from the developer console of your browser? This is invoked by F12, then select "Console" tab. Errors would be red, so you can see them well. The builder is not flash based, this is pure HTML5 application. You may try to disable add-ons (in your browser), perhaps something is colliding (for me it does work with UBlock Origin). Cheers
  3. Dear @costa, i don't think so... look: https://gdtf-share.com/gdtf.php?page=home&query=strip&man=1&fix=1&rev=1&use=0 Kind Regards Petr
  4. Just tried on Windows 8 Pro (Chrome, Firefox), all without issues, our GDTF person is using it daily from Win10 systems and i use it daily from my Debian Linux with Firefox (Chrome, Chromium also tested) without any issues.
  5. Yes, orientation of the axis is given, which allows for moving heads but also for moving mirrors to work. We clarify this a bit more in 1.1 for moving mirrors (scanners). The pigtail position then indicates the real (cable connection) position, giving you the true orientation of the device. See our fixtures, their pigtail is in correct place in relation to pan/tilt movement. Also the SilverScan works well in visualizers, thanks to it's default "stand up" orientation, aligning the axes "correctly".
  6. Yes, Rex is correct, the pigtail is to indicate the orientation for correct model→real device alignment.
  7. Strange. Do right click → Save link as. I will upload it to YouTube or Vimeo. Anyways, i made a small mistake (didn't rotate the head one more time) so had to do a bit of time travel via copy/paste while editing, so am thinking to re-capture it, that is why i didn't upload it to any of the platforms yet...
  8. We have uploaded updated Robin megaPointe, Robin LEDWash 800X, Robin SilverScan and Robin Viva CMY to the share this week. Also, i have created a short video screen-cast on how to prepare 3D models for usage in the GDTF Builder, by using only freely available tools, see it here: http://spares.robe.cz/static/images/gdtf_video.html EDIT: Added link to newer video, link now points to a page with embedded player.
  9. Dear all, we have been producing tests files for a long time and have switched into a final version releases now. What we are aiming for is about one library a week. What takes longest is physical attributes measurements (movement, strobing, iris...) and testing to match visualization. The rest - models preparation, geometries, media content, color-metric data, DMX... is possible to do in about two/three days. You can find our files under our official account: https://gdtf-share.com/user.php?name=Robe+Lighting+s.r.o.&page=fixtures And what we are missing is feedback - we do receive some from our customers, but are open to further information in case anything strange/bad is found, so please feel free to report here or to our dedicated email libraries@robe.cz . thank you
  10. Hi all, best way to understand this is not to think about how you control it, but how will a visualizer know what to do. So you have Shutter open/closed, Strobe, Strobe Pulsing opening/closing etc. As each of these require different way to visualize, each requires a new Channel Function with it's attribute. cheers Petr
  11. Hi Matt, thank you for bringing this up. Yes, this is has recently been reported and will be fixed in next builder update, cheers P.
  12. Hi NRG Sille, >but if I leave the reference without a patch if you do not patch the beam geometry, visualizers will need to instantiate it and give it an intensity by the grand master, which the user will not be able to dim down... >It seems that every beam has to assigned to a seperate geometry. You would typically do a reference geometry. Cheers P.
  13. Hello, we do actively test and use Firefox and Chrome. What browser do you use? It is not clear from your screenshot. Work is typically not lost, but stored in browser local storage, re-opening the page allows you to re-load the last edited file. thank you Petr
  14. Hi Matt, >Nah, I'm talking about the location that the Continuous attributes are defined, as they seem to be under control right now, which per manufacturers, those are not a control function, they are still defined as a position attribute. The range of movement is in the PhysicalFrom/To attributes of channel functions: <DMXChannel Geometry="Yoke" Default="128/1" Offset="1,2"> <LogicalChannel Attribute="Pan"> <ChannelFunction Attribute="Pan" DMXFrom="0/2" OriginalAttribute="Pan" PhysicalFrom="225.0" PhysicalTo="225.0" RealFade="3" Name="Pan"> Any channel can, through Mode Dependency, evoke another ChannelFunction with different PhysicalFrom/To range, e.g. 360°. We are also tracking a request to have a dedicated attribute to determine if rotation is +/- 180 , +/- 360° or continuous 360°. I do not understand your second comment. We have been working on an open specification to actually allow people to make it possible to create visualizers, apps, control systems etc, or to use this data in already existing system. The builder is a tool to create GDTF files according to the GDTF specification, it is not an application to visualize the real result. I think the confusion here is free and open specification (free as in speech and beer) and free visualizers (free as free beer). Hope this helps Petr
  15. Hi Matt, do you men the current limitation to not spin the model all around? This is intentional, to allow good work with the model and is different then being able to define the pan/tilt range as 0-360° / -180°/+180°. The builder is not really a visualizer. Sorry if i misunderstood. cheers Petr
  16. Hi Matt, as you mention, the specification itself supports geometry referencing, which helps a lot. Optimizing the workflow is certainly on the road map. cheers P.
  17. Materials and textures could be defined in the 3DS and although for now the GDTF specs does not mention this at all, this is more related top 3DS specification rather then GDTF spec. Texture visualizing could be done in the builder in the future, the underlying library does support it, but as Rex pointed out, the real work must be done in visualizers.
  18. Good morning ? We have looked at it and the issue is very simple. 3DS models have no dimensions in any defined unit. It is for example 2.00 or 5.00 or 172.53 . It is then up to the software to make something of it. MA2 3D is interpreting these as meters. GDTF Builder is interpreting these as millimeters. VectorWorks and Vision are interpreting these as millimeters. So one possible solution is to have a checkbox on the import dialog (where you already specify "Use 3D model's dimensions") to choose if these are mm/m. But what we must take care about is how these get also exported. So right now, before we explore all caveats of this, if you are building files, you can easily make this work by defining sizes in millimeters, either in the model directly, or in the builder itself. ?
  19. I have checked your file in another tool and it shows the same size. 2x2x2mm. I actually do not see any issue in the builder... i tested your file: when it imports, size is correctly either at 2x2x2mm, or, if i set the size manually, before the import, the size is applied correctly. To me, the settings in your original program are not as you expect, when again, checked not only in the builder but also in unrelated 3rd party software here. But i do not know C4D to be able to help you there.
  20. Actually, i do see the qube in the builder and i think you do too, but the issue is in size. When i calculate box dimensions for this model, in MeshLab, here is what i get: Mesh Bounding Box Size 2.000000 2.000000 2.000000 That is in milimeters. So the units are somewhat off. So it is really tiny and this is why you "cannot" see it. See attached Esprit head, so comparison. Cheers Petr head.3ds
  21. Hi Rex, we do no use C4D, we model stuff is Solid Edge and convert in various tools to 3DS, for example some manipulations and mesh simplification, together with final export to 3DS are done in MeshLab. Can you provide your 3DS file here please? Or link to a GDTF file with that 3DS inside? thank you
  22. Model file name, model name and geometry name are three separate things. You can have one model (with it's file name and name ) being used (linked) in multiple geometries (of different names). Therefore what you want to change is geometry name, not the model name - that is only a link to the model. At this point, file names cannot be changed in the builder, but you have full control over them when creating these (3D) files. ... if i understand you correctly... ? cheers P.
  23. Hi Rex, this certainly is not my experience, actually, the addition of reading dimensions from file is great as you do not have to get the box dimensions of the model. See attachments here. Or am i looking at a different thing? Cheers Petr
  24. Hi Matt, yes, it is basically the icon displayed on drawings, it should be a Top View, at the moment. We have not been adding it to our (Robe) files yet. Cheers Petr
  25. Hi Rex, the builder is pretty unrelated to this. The MVR is a specification of this encapsulation, GDTF is an individual component. The encapsulation is then done on the device where you create the scene itself (for example desk → push into visualizer, or the other way - make planning in VW → push into the desk)... hope this helps Petr
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.