PDA

View Full Version : LOD - Another Point of View



andi06
September 20th, 2015, 06:26 AM
I've received a pm from a user on the subject of polycount validation, its a long message so I will summarise:


Imposing a poly count limit/warning thing to objects, is a severe restriction on the way you can use the game. You are forcing users to use the game in a certain way. I use the game a little different to most, I like to run really heavily detailed loco's and rolling stock and I'm not keen on the eye candy around the track and scenery objects so I sacrifice this for the other. So you are telling me I can't do this now because of this limit. Think it out properly. I don't upload these to anywhere for anyone else to use. But I now have to make them only your way. Its just another reason not to use Tane. This game is screaming out for for the users kuid to be exempt from this validation rubbish on their own computer.

Also I have some really Hi poly industries I have made, I am totally comfortable about them I fully understand their resource hogging features. The thing is they are important to me and I want to see them that way. Why can't I, because of some unnecessary limit. Surely you should be making the game more versatile, not specialized, isn't that why so many creatures go extinct.

It is totally true that we have all been discussing content creation on the unspoken assumption that the objects will be published for others to use. There is plenty of evidence on the forums that many users build for their own enjoyment and don't upload and it is also one of the greatest strengths of the game that it has, in the past, been one of the very few programmes that makes the act of creating something widely accessible.

It would be a shame to lose this aspect of the game.

WindWalkr
September 20th, 2015, 08:04 AM
I have two comments on that; one for and one against:

AGAINST: Nothing that we've discussed so far involves adding polygon-count restrictions. This is something to keep in mind if we ever were to head down that path, but has no effect on the current discussions. T:ANE is by far the least restrictive version of Trainz in recent history.

FOR: Enforcing proper use of LOD does make things more complicated for the creator, in exchange for performance. That might be a bad deal if you honestly don't care at all about performance. I will contend that it's an extremely small minority who honestly don't mind running the game at 1 fps, so there's a balance here somewhere.


chris

andi06
September 20th, 2015, 09:09 AM
I don't think its a small minority who build assets and don't publish them, and no doubt the guy is overstating his case for effect (as we all tend to do).

What is probably at the back of this is that complying with errors that are not 'fatal' to the game is viewed as a set of hoops that have to be jumped through and there is no doubt that validation rules do make it more difficult to get objects into the game.

A means of relaxing validation errors for non-published assets would be EXTREMELY popular. They might even start taking a vote to send YOU some freebies.

WindWalkr
September 20th, 2015, 09:29 AM
I don't think its a small minority who build assets and don't publish them, and no doubt the guy is overstating his case for effect (as we all tend to do).

I didn't suggest it was.

I do have a concern with bucketing this group, however. Just because you create an asset for yourself today doesn't mean that you won't turn around and want to share it tomorrow. Good creators have to start somewhere. Using "one rule for the standalone creators" and "a different rule for the community" sounds like it would make it harder for these guys in the long run, even if it's a little simpler up-front.



What is probably at the back of this is that complying with errors that are not 'fatal' to the game is viewed as a set of hoops that have to be jumped through and there is no doubt that validation rules do make it more difficult to get objects into the game.

Without a doubt, there is more effort in following the rules than there is in just doing whatever pops into your head. It would be hoped that the end result of following the rules is superior, but I don't think anybody would argue that it makes life easier to start with.



A means of relaxing validation errors for non-published assets would be EXTREMELY popular. They might even start taking a vote to send YOU some freebies.

See above about my concerns here. Also, define "published"- doing it in a way that locks the content down to a particular user's machine might prove somewhat unpopular with at least a segment of these hypothetical users.

chris

andi06
September 20th, 2015, 09:46 AM
I do have a concern with bucketing this group, however. Just because you create an asset for yourself today doesn't mean that you won't turn around and want to share it tomorrow. Good creators have to start somewhere. Using "one rule for the standalone creators" and "a different rule for the community" sounds like it would make it harder for these guys in the long run, even if it's a little simpler up-front.
Not knowing the Highway Code never stopped anyone from learning to drive and there may be advantages in just getting behind the wheel rather than having to read the whole book first. If and when the people in question want to share their assets they will add validation compliance to their list of skills.

The other counter to this is that it would also be popular with experienced creators simply because they would be able to chose WHEN their assets are made fully compliant. I will give you two examples, one of which is trivial, the other is a major obstacle to content creation.

1. You are in the earliest stages of building content, you try to commit it to the game and you are confronted by a requirement to specify a category-class tag. You know that this is a total irrelevance at the current state of play but you are still forced to deal with it now rather than later.

2. You have an asset which is drawing LOD errors and you can't make sense of them. Loading that asset into the Preview window and checking the stats will solve the problem but you can't do that because the object has LOD errors and won't install into the game.

Whatever concerns you might raise, the answer is that you would be providing a choice which doesn't currently exist. I would invite anyone (except you) to post here or send me a pm if they think that such a choice would be a bad idea in principle.

norfolksouthern37
September 20th, 2015, 11:56 AM
we could certainly use some sort of development mode that you can put an asset in and have it restricted in such a way that you cannot upload it (or save to cdp maybe?) until all of the required checks are passed. Simple form yes, but that would be very helpful to just making a better high quality and correctly functioning asset in the end.

pcas1986
September 20th, 2015, 02:18 PM
I agree that an "Asset in development" tag would be useful. By all means leave the errors in place but downgrade them to warnings and impose restrictions as suggested. Making traincars has gotten a whole tougher recently and attracting new content makers will be harder.

oknotsen
September 20th, 2015, 03:45 PM
we could certainly use some sort of development mode that you can put an asset in and have it restricted in such a way that you cannot upload it (or save to cdp maybe?) until all of the required checks are passed. Simple form yes, but that would be very helpful to just making a better high quality and correctly functioning asset in the end.
I agree that an "Asset in development" tag would be useful. By all means leave the errors in place but downgrade them to warnings and impose restrictions as suggested. Making traincars has gotten a whole tougher recently and attracting new content makers will be harder.These sound like a very interesting idea.
Especially if the warnings would supply enough text or a link to very clearly described help documentation on how the assets can be upgraded to the level they can be shared / will make it to the bigger community.

This makes it possible for people to "just" use that ridiculously high poly building out of Sketchup for own use, but on the other end prevent those assets from ever wasting DLS space again.

VinnyBarb
September 20th, 2015, 05:52 PM
I am also for this as andy06 and Justin posted above. This will give a Content Creator to see in his/her PC what his/her final asset might look like BEFORE starting say, LOD reduction, worrying of any correct tags, configuration etc. Nobody gets harmed that way as no uploads are involved and this would be a good instrument too, as said, to show a created asset in progress, what this will look like without some errors preventing it to be seen, be it in preview or in Surveyor.

VinnyBarb

WindWalkr
September 20th, 2015, 06:47 PM
The two approaches I have been mulling since we last discussed this:

1. We could simply allow any faulty assets to load into the game if you're in Developer mode, as long as they match your UserID. This is the easy approach for us, but might not work well for groups of content creators.
2. We allow tagging of a small number of assets as "in development". This number needs to be high enough to be useful, but low enough that end-users don't simply try to tag their entire content set. This also doesn't solve the concern raised in the first post.


As yet, both have downsides which may make them non-starters for some users. It's feasible to implement both, which *may* be enough.

thoughts? alternatives?

chris

RRSignal
September 20th, 2015, 07:09 PM
The first of the two seems sufficient to me.

VinnyBarb
September 20th, 2015, 09:37 PM
I concur too with the first approach, group content creators can simply change the user ID to their own in such asset's configuration to see these in developer mode. No harm will be done by this to anyone as my guess is, a user group not only exchange Kuids or CDPs among themselves but also folders of these assets where this can easily be changed for testing.

VinnyBarb

andi06
September 21st, 2015, 03:22 AM
I would say that Option 1 is preferable.

Pencil42
September 21st, 2015, 08:54 AM
I like both. Option one would work most of the time, but sharing something with multiple dependencies (like track, for example) in a dev environment could be problematic. In that case, one might need to change many kuids to get the asset to load, opening the door to additional errors.
If we go down this route, a query term in CM for finding 'whitelisted' assets would be nice.

Curtis

clam1952
September 21st, 2015, 09:29 AM
Prefer Option 1 myself as it's keeping things simple.

whitepass
September 21st, 2015, 09:41 AM
What if with Option 1 a new CC made an error that would crash or lock up Trainz do?

andi06
September 21st, 2015, 09:45 AM
We're only asking for the suppression of non-fatal errors so this should never arise.

WindWalkr
September 21st, 2015, 10:02 AM
Unfortunately there's no way to distinguish between fatal and non-fatal errors, so that can definitely happen.

In theory, errors should still be caught by other systems so ideally a complete crash won't occur (although all sorts of other weirdness might.) In practice, who knows- that's why we have a validation system.

chris