Railclone color support for Vray RT

[sebastien_berthier]

Are you planning on developing support for this map?

[Miro]

It's on our to-do list but we cannot give you an exact time frame for when or if it will be implemented.

[glorybound]

Two years later and no support for it? I am not sure how you can use RailClone without RailClone Color. Does this mean nobody is using RailClone and GPU?

[sebastien_berthier]

Use Multitexture script from cg-source. randomise the material id in railclone and assign different maps according to material id

dont forget to disable the instancing of the railclone object

[glorybound]

Yeah, thanks, but years later you would think it would have been implemented. Almost all RailClone styles use it. Every time I try to use GPU, I hit roadblocks like this.

[sebastien_berthier]

It s indeed a bit cumbersome to disable the instancing each time.

[sebastien_berthier]

and true again. It s been two years...

[savage309]

and true again. It s been two years...

Realistically, I am sure that every possible feature has been requested for the last 10 years for V-Ray by someone.

So you could say the same for literally every feature that anyone could possible imagine that hasn't been added yet "and is has been N years" .. When I look at the change log, it is not like nothing was made in the last two years .. quite the contrary.

Best,
Blago.

[glorybound]

Realistically, I am sure that every possible feature has been requested for the last 10 years for V-Ray by someone.

So you could say the same for literally every feature that anyone could possible imagine that hasn't been added yet "and is has been N years" .. When I look at the change log, it is not like nothing was made in the last two years .. quite the contrary.

Best,
Blago.

Agreed, however, don't most all RailClone styles use the RailClone Texture? Basically, if you want to use RailClone you can't use VRay NEXT GPU or if you want to use VRay NEXT GPU you can't use RailClone.

[andy51]

While there are plenty of people that use Vray Next GPU, there are also plenty that do not and I am one of them.. CPU / IPR yes, but unless you have some top end GPU car(s) installed, there isn't any great improvement. I use Railcone, Forest Pack Pro and so far, I have absolutely no requirement to use GPU, so for me, this problem just doesn't exist. Then again, a lot of feature available when using CPU, are still not available for GPU and only time and a lot of hard work, will change that. When the Chaos Cloud was fist introduced, it seemed like finally there was a very fast rendering solution, for everyone, however, with it's lack of support for various plugins, such as those used for VMPP materials etc, I found it was only of any use, for quick tests, whether those problems have been addressed now or not, I do not know, but now that the cloud is no longer in beta, I don't see me needing to use it.

Fact is, you can never please al of te people al of the time, there will always be a feature that some want, or a problem they need a solution for.. Many will eventually get sorted, though some may not be as much of a priority as others.

Since Railclone is not a chaos product, I would imagine they would not have such a request as high on the list as those which apply to their own product(s)

[glorybound]

I don't know if the other GPU solutions support RailClone, but if they do, I can imagine it being a major factor in deciding which GPU solution to go with. ITOO software is a major player, so I can image it is pretty high on the list of plugins to support. Actually, I would assume it is the highest on the list of plugins used. If it is indeed one of the highest, if not the highest, than RailClone Color would be top priority, since you can't use a lot of RailClone without it.

[sebastien_berthier]

Railclone and Forest pack are of standard use for the whole arch viz scene. It is not a niche plugin!

But I can foresee the complexity to implement it.

[^Lele^]

It's more a case of priorities: once the devs get on a task, it generally gets done.

This is the ideal scenario only, however.
Reality is rife with roadblocks and unforeseen issues, particularly as GPU coding is concerned (it's *really* hard to debug, i hear, and generally a quickly moving target, compared to CPU development.).

As the feature is a third-party one, that alone adds a layer of shifting, uncontrollable issues.
In the case of something not readily solvable, a feature gets put on hold, until a fix is found, or implemented by the third party in question.

I tend to agree, however, on the massive use of iToo software in nigh any max-bound archviz scenario.
But read nothing else into it, the GPU team is full of work as it is, and while i'm sure they'll try their best to accommodate this too, it's for them alone to ultimately choose priorities.