I would assume alot of the areas have collisions, in the style of Westhill.
Keep in mind that alot of "backstage" regions are also covered in screenshots and made detailed.
There are also official LFS videos from the various parking lot buildings. So they are indeed accessible.
Retopoing my subsurf based highpoly model to a game compatible lower poly model
Episode one
https://www.youtube.com/watch?v=8q3I3XDgXvk
Episode one
https://www.youtube.com/watch?v=8q3I3XDgXvk
That's fair enough. I guess it was just a typo on your part. But yea, even in our democractic systems where officials aren't poisoned by other officials. We as citizens don't have a great deal of influence military stuff other than how much money to allocate.
And I don't have anything against russians as long as they aren't kremlin supporters.
Thank you
Ironically you really emphasized the distinction between government and people in Russia. But then went on to say that the western people support war with their deeds.
Can you post the wireframe in non PSD format?
I'd like some feedback this early in fact from a reviewer. I don't wanna spend time on something if it turns out I don't have enough evidence for my ownership of my mesh.
Used blueprint:
Old state of model placed under blueprint.
Orthographic comparison view of newst (2022 save) and oldest (2015 save)
Proportional and topological changes have been done. But some edge loops can be identified between the two iterations.
Please also do notice that the 2022 version use subsurf tricks, especially at the roof and door handle which wouldnt make sense in any other circumstance than a self modeled mesh.
You can also see that the dashboard is heavily subsurf based.
Used blueprint:
Old state of model placed under blueprint.
Orthographic comparison view of newst (2022 save) and oldest (2015 save)
Proportional and topological changes have been done. But some edge loops can be identified between the two iterations.
Please also do notice that the 2022 version use subsurf tricks, especially at the roof and door handle which wouldnt make sense in any other circumstance than a self modeled mesh.
You can also see that the dashboard is heavily subsurf based.
Last edited by pärtan, .
Hmm not really. The scan itself have no impact on the topology. The scan gives a very messy high poly mesh that then has a new topology imposed upon it. The scan data is something which very closely resemble the shape of the real, mass produced vehicle and so two different laser scans can be hard to tell apart. The retopology is technically the only artistic attribute of such a mesh. Thus second retopology could be considered a different interpretation of the original scan data.
Point is it makes the cube analogy somewhat accurate as it is also a shape you can reproduce in an identical manner for two separate parties.
I'm not trying to convince anyone that retopos should be allowed. I simply don't agree that the cube analogy is inaccurate in the case of laser scanned models.
And about the part where we should just suit ourself for not having prepared our 7 year old meshes for proof of ownership in the future. Just make me aware if I'm about to waste my time on modding before I'm done modding is my point. Because the level to which I have to redeem myself is very vague and abstract.
I don't agree with this, especially when dealing with cars. A car is a mass produced tangible object with a very specific geometry. For example, every single 1995 opel corsa (just as an example) will have exactly the same geometry and dimensions with the exception of panel fitment or potential damages.
This means that when you use the methods of large game studios which is to do a very detailed laser scan process, your mesh don't deviate from the real geometry. Thus it's no longer unique to that game studio. Anyone with access to decent photogrammetry or laser scanning would be able to reproduce a mesh that is indistinguishible from a retopology of the other games laser scanned mesh. Because they share the fact that they are both essentially just measured data from a real mass produced object.
The only unique aspect of such a model is its topology, which is completely disregarded in the retopology process. Think of it like doing a retopology on a raw laser scanned model but with extra (and controversial) steps. So in that sense I think the cube analogy isn't entirely off base.
With that being said, if the devs don't wanna allow this, that's up to them. Because the laser scanning job is unarguably something that costs money to do.
Exactly. Using screenshots of potential orthographic mesh views from games. Or high quality blueprints that are potentially based from ripped models falls under the same legal problems (or moral) as retopoing a model. It's something that might sound silly, but is worth thinking about.
This is problematic in some cases. For example if you have an old, blueprint made model that you're sitting on and want to turn into an LFS mod. This model could lack the "documentation" and you're back to taking someones word for it. In the case of my Civic EG model, I do have some documentation in the form of older blender files, but historically I have not thought about having to prove ownership of my model in the future so wip screenshots and videos are not to be found in this case.
The whole burden of proof thing that has come up here could essentially force you to having to start over and making new models for your LFS mod projects. I feel that this could potentially turn into a problem for my EG project. Of course I hope it's gonna be smooth. But putting 10, 20, 30, 40 hours into something with nothing but hopes that it's gonna go smoothly phrankly isn't good enough.
I think a solution to this could be to get reviewed earlier in the development process. Like as soon as you post the wip thread with whatever information you have about your mesh. Then get the green light to go from there.
Last edited by pärtan, .
Oh, its not a Datsun, it's a Honda.
Thank you very much
Long running project. One of my oldest projectsVicic cg6
The project is a car based on the Honda Civic 5th generation.
My previous project was a retopo of another game mesh. I have since learned that those mods are not appreciated by the developers. So instead I thought I'd pick one of my blueprint made models. And this one is made from start to end by me.
I don't have a huge backlog of WIP images, but I have older blend files from earlier in the progress (dating back to 2015).
I have picked it back up a few times to bring it up to standard as my modelling skill have improved.
I have attached a comparison of the same model from 2015 compared to now.
It will take some work to bring this model to a game ready standard as it's currently heavily subsurf based.
But here are some images of how the model look.
Just for fun I thought I'd show the gauge cluster I made for it, because I think it looks good. It can obviously not be used in LFS though
If you have a better naming idea, let me know.
My previous project was a retopo of another game mesh. I have since learned that those mods are not appreciated by the developers. So instead I thought I'd pick one of my blueprint made models. And this one is made from start to end by me.
I don't have a huge backlog of WIP images, but I have older blend files from earlier in the progress (dating back to 2015).
I have picked it back up a few times to bring it up to standard as my modelling skill have improved.
I have attached a comparison of the same model from 2015 compared to now.
It will take some work to bring this model to a game ready standard as it's currently heavily subsurf based.
But here are some images of how the model look.
Just for fun I thought I'd show the gauge cluster I made for it, because I think it looks good. It can obviously not be used in LFS though
If you have a better naming idea, let me know.
Last edited by pärtan, .
It is? I haven't found this attachment type.
But to go along with this. The ability to not render / use the generated wheel barrell and spokes. And in place use subobs for wheels.
The biggest problem for me isn't whether or not retopos are allowed. But it's just not made clear enough. I did take a look before starting my retopo project which included reading a list of banned model sources. I also asked in the LFS discord where I got the impression that retopos would be allowed. Especially considering there are retopos in the game already.
Then I found this whole discussion mostly contained in various mod review threads.
So what is needed is more clear communication, and more easily accessed guidelines which explain your stance on retopos and state that they are not allowed. It's a good way to stop alot of it. I wouldn't have started on my retopo project had this been the case for example.
Now, before I start on my next mod. I would like to know a few things which seems to have been indicated already:
What sort of blueprints are banned / allowed? If I find a blueprint that have been rendered from an unlicensed game model, does that fall under the same legal category as a retopo?
Do I have to video the whole modelling process to prove that I have not made a retopo in the future?
I'm not trying to be difficult. I just wanna know what I have to think about considering we invest our time into modding.
Then I found this whole discussion mostly contained in various mod review threads.
So what is needed is more clear communication, and more easily accessed guidelines which explain your stance on retopos and state that they are not allowed. It's a good way to stop alot of it. I wouldn't have started on my retopo project had this been the case for example.
Now, before I start on my next mod. I would like to know a few things which seems to have been indicated already:
What sort of blueprints are banned / allowed? If I find a blueprint that have been rendered from an unlicensed game model, does that fall under the same legal category as a retopo?
Do I have to video the whole modelling process to prove that I have not made a retopo in the future?
I'm not trying to be difficult. I just wanna know what I have to think about considering we invest our time into modding.
Last edited by pärtan, .
Just to play devils advocate.
The workflow many games use to make high quality car models involve laser scanning a real vehicle. It's not a particularly artistic process, but a technical one. The geometry very closely resemble the real object (car) that have been scanned, and the 'personal touch' comes from their topology. That is essentially the only unique attribute their mesh have versous other models scanned from the same object.
A retopology disregard that attribute, and only utilize the geometry data of said model which again very closely resemble the geometry of the real car.
But of course, it is true that the creator of the original mesh have invested in the scanning technology/process.
A correct version of the tracing analogy in my opinion would be: You want to trace a painting, but don't have access to it. So you trace an already traced version of the painting instead because it yields better results than trying to hand draw the painting.
Either way, I'm not trying to convince anyone of anything. But what would be a good idea is a clear set of rules for what is allowed and what is not allowed in a pinned thread touching on the following things:
Retopology
Blueprints (which blueprints are okay to use)
Image-modeler (it's a powerful tool to make car models, but it's no longer attainable trough legal means)
Also, what about image licensing for modelling with Image Modeller.
Resemblance of real cars. Is there a limit to how close you can go.
These things might sound silly. But it's good to have a solid set of guidelines to refer to since it's time consuming to make mods whichever method is used.
The workflow many games use to make high quality car models involve laser scanning a real vehicle. It's not a particularly artistic process, but a technical one. The geometry very closely resemble the real object (car) that have been scanned, and the 'personal touch' comes from their topology. That is essentially the only unique attribute their mesh have versous other models scanned from the same object.
A retopology disregard that attribute, and only utilize the geometry data of said model which again very closely resemble the geometry of the real car.
But of course, it is true that the creator of the original mesh have invested in the scanning technology/process.
A correct version of the tracing analogy in my opinion would be: You want to trace a painting, but don't have access to it. So you trace an already traced version of the painting instead because it yields better results than trying to hand draw the painting.
Either way, I'm not trying to convince anyone of anything. But what would be a good idea is a clear set of rules for what is allowed and what is not allowed in a pinned thread touching on the following things:
Retopology
Blueprints (which blueprints are okay to use)
Image-modeler (it's a powerful tool to make car models, but it's no longer attainable trough legal means)
Also, what about image licensing for modelling with Image Modeller.
Resemblance of real cars. Is there a limit to how close you can go.
These things might sound silly. But it's good to have a solid set of guidelines to refer to since it's time consuming to make mods whichever method is used.
This one just came to my mind.
What about using OBJ materials to create dummy mappings.
And the same thing for importing LFS models (saved mappings)
Then also have existing mappings of the object you're overriding being inserted to the mapping slots of the object you import.
What about using OBJ materials to create dummy mappings.
And the same thing for importing LFS models (saved mappings)
Then also have existing mappings of the object you're overriding being inserted to the mapping slots of the object you import.
I'm putting this project on hold. I worked on this project under the assumption that retopos was tolerated. But it seems that it's not certain they are. So I will not work further on this until I know what's going on with that.
No it's not. The model is RHD as default, so thats why the battery position is on the left:
I'm not making the suspension based on "feeling" or what I like or not. I have measured over 30 different measurements on a real civic to deduce the actual geometry of the suspension points. Here you can see a diagram I made from the front suspension:
The problem is you can't make a correct suspension for this car. I chose the compromise which is to simply lower the entire suspension on the car body until the hub ends up in the center of the upright. It seemed like the easiest solution until more suspension options are added to lfs.
Thanks for the feedback.
Last edited by pärtan, .
Can't answer why they do it this way. It could be to get a certain camber curve, or for packaging reasons. But it is like this in many cars.
Some examples are:
Honda CRX, Civic EF, EG, EK
Toyota/Lexus IS200/IS300 Chaser JZX90, JZX100, JZX110
And most newer Audi Quattro models if not all.
Last edited by pärtan, .
Thanks for the offer, but it's not needed because as I said in the first post the suspension is already done.
I have already gone trough the effort of measuring all the suspension points on an EK chassi myself.
Problem with suspension is that LFS doesn't support the correct geometry. The hub needs to be placed in the center of the upright, which means I have had to make compromises in the form of moving the entire suspension down.
It throws off the roll center but the camber curve is correct.
If more options for suspension geometry is added in later, then I will fix it at that time.
Last edited by pärtan, .
With more and more mods being added, its getting harder and harder to navigate. I think the mod list needs more filters.
A "Drift" class would be a good idea because there are many drift car mods that don't really fit into existing classes.
Also a way to filter based on driveline type.
The more filters the better basically.
A "Drift" class would be a good idea because there are many drift car mods that don't really fit into existing classes.
Also a way to filter based on driveline type.
The more filters the better basically.
Asymmetric uprights for double wishbone
I noticed something while trying to replace measurements i took from a real suspension in the LFS editor.
I dont know if this is a technical limitation of some sort to do with stability of the physics engine. Or if it simply is a feature that so far have not been needed.
Basically, currently you can only adjust 'half upright' which results in an even distribution of length above and below the hub line.
Many production cars with double wishbone suspension have a significantly longer upper portion.
I don't think there is an optimal way currently to replicate these suspensions
You could elongate the upper control arm but this results in a different camber curve.
You could also lower the upper and lower pivot points to compensate for the difference in hub height, but this results in a different roll center.
Would be a neat improvement to be able to adjust the upper and lower portion independently
I dont know if this is a technical limitation of some sort to do with stability of the physics engine. Or if it simply is a feature that so far have not been needed.
Basically, currently you can only adjust 'half upright' which results in an even distribution of length above and below the hub line.
Many production cars with double wishbone suspension have a significantly longer upper portion.
I don't think there is an optimal way currently to replicate these suspensions
You could elongate the upper control arm but this results in a different camber curve.
You could also lower the upper and lower pivot points to compensate for the difference in hub height, but this results in a different roll center.
Would be a neat improvement to be able to adjust the upper and lower portion independently
BeamNG generates sounds trough a blend of a series of sound samples. I think it's similar to how rFactor does it.
There are 4 different samples sequences used at various RPMs. So one for intake onload, one for intake offload, one for exhaust onload and one for exhaust offload.
LFS does something more similar to the engine simulator where it synthesize a waveform in realtime based on an engine simulation. Although LFS engine simulation is not as advanced as that in the engine simulator program.
I think LFS is already on the right track for making realtime engine sounds. You'd have to simplify the engine simulator quite a bit to get it fast enough to intergrate in a game. But of course there is always room for improvement with more drone resonance and valvetrain noises and such.
Last edited by pärtan, .
This is definitely very impressive. But there are a couple of things to consider here.
This program runs on a 10khz rigidbody system and more importantly an 80khz fluid simulation which means it's a quite resource heavy synthesizer to run in the background while also running the LFS itself efficiently.
In a way it is similar to the engine sound generation system in LFS. The difference is that LFS spams pulse samples with processing applied, while this system generate a sound wave trough the resource heavy fluid simulation.
Bottom line is that it's quite heavy on the CPU
You do realize that this post makes you look like the child.
FGED GREDG RDFGDR GSFDG