Introduce text-based file format for scenes and models

Requests or suggestions for new features
Post Reply
gvgramazio
Posts: 18
Joined: 23 Feb 2018, 14:46

Introduce text-based file format for scenes and models

Post by gvgramazio »

In an old topic (2015) and in a very old post (2013) were discussed the introduction of text-based file format for scenes and models.

The best advantage would be of course the possibility to introduce version control when working with V-REP. I suppose that almost everyone here is a programmer and know what is version control and how important it is. Without version control is almost impossible to work on a V-REP project in a team and even working alone there are several problems like not knowing which are the difference between two version of the same model/scene. I showed V-REP to several people and even if enthusiastic about how it works all of them told the same thing: "Without the possibility to use version control we'll not use it and you should do the same".

Another advantage would be to create models (and maybe scenes) with other language programs.

In the old topics, coppelia answered that it is an important feature and that it will have been pushed to a higher priority todo-list. This happened three years ago. My question are:
  • It's still in the todo-list?
  • If yes, we will see this feature anytime soon?

coppelia
Site Admin
Posts: 10336
Joined: 14 Dec 2012, 00:25

Re: Introduce text-based file format for scenes and models

Post by coppelia »

Hello,

I perfectly understand your concerns, and I have to admit that this task has been pushed up/down quite often in the priorities list. I am not going to adventure into giving a release date of such a feature, since it will very very probably not be met, as we encounter higher priorities along the way all the time.
One workaround to this problem is following:
  • Do not use scenes, or only very static content scenes. Use models instead that your dynamically load into the scene (e.g. via an add-on script or via a customization script)
  • Do not write your script code inside of V-REP directly. Instead, use require('/myProject/myScript') inside of your scripts, so that they reference external files
  • Programmatically (via those externally linked scripts)load and place your models, configure them, etc.
Cheers

gvgramazio
Posts: 18
Joined: 23 Feb 2018, 14:46

Re: Introduce text-based file format for scenes and models

Post by gvgramazio »

Thanks for your reply, Coppelia. I hope that you'll implement it very soon.

What workaround do you suggest to create models instead? Some models could be very complicated and suffer the same problem.

gvgramazio
Posts: 18
Joined: 23 Feb 2018, 14:46

Re: Introduce text-based file format for scenes and models

Post by gvgramazio »

I tried to work only with scripts and there are two main problems. The first one is that by using only regular API I don't use at all the GUI of V-REP thus is like having a simulator in terminal mode. It works, but it lost 90% of its easy usability. The second one is that just a little portion of the regular API have their correspondent in the remote API. This means that I have to rewrite a lot of functions with the help of simxCallScriptFunction, thus writing both in Python and Lua.

I don't want to complain here, it's just to say that the workaround has a lot of limitations and drawbacks. I really hope that in the future you will implement a text-based file format because it could attract a lot of users and it will stop your current users to migrate toward other simulators.

coppelia
Site Admin
Posts: 10336
Joined: 14 Dec 2012, 00:25

Re: Introduce text-based file format for scenes and models

Post by coppelia »

About the remote API not offering all desired functionality directly:

this is currently true: the remote API functions are a sub-set of the regular API functions. As such, unimplemented functions will have to be wrapped inside of a script function, itself called via simx.callScriptFunction, as you mention it. This works, but is quite troublesome.

In next release, there will be a new version of the remote API, based on BlueZero. In that new framework, it will be much easier to add unsupported API functions to the remote API.

Cheers

Post Reply