maybe not so easy to implement but still would be great as very few mods take advantage of vertex shading
the process of assigning shading to those vertices is also time consuming
we could then have some way to compute a basic ambient occlusion and bake it into those vertices automatically
These settings will allow import obj files directly from LW to LFSE and preserve smoothing groups.
As u wrote smoothing groups are not used in lfse import, I unchecked that option.
I'd never thought that merge points option since I always merge points and cleanup things for realtime use.
So I tried and haha, it works. Groups are preserved in lfse.
I use Lightwave since 1994, build things for realtime since 2002, and still learn new things...
here is a link to that pair of triangles u want to check (with the merge points option ON) https://pastebin.com/GeuZAqnm
@drifteris
but i didnt ask for help, this is a suggestion thread.
I could have phrased it better however yes.
@scawen
I agree it would be nicer if the obj import could work out the smoothing groups right.
I made some test export with blender and lightwave modeler, and it seems they output 2 slightly different obj files for the same object
the blender one will import smoothing groups correctly in lfse, the lighwave output wont.
edit: the lightwave obj output will load correctly in blender
edit2:
as lighwave obj loads into blender I tried export that lw obj from blender to lfseditor and gee ! groups are preserved !
That is a very simple way to get what I want, so my suggestion isnt so meaningfull now, no need waste time on it : )
lol ? did i ask for a 3d modelling course ? I hate unsollicited teachers.
how is it u feel obliged to explain me those useless "tricks", and assume I am working in blender with quads ? huh ???
I cant preserve groups when importing an obj that has been built and saved with them.
Poly selection by angle threshold is available for years on some 3d modelers, it is simple usefull and saves time, much more than those complicated "tricks".
To me, this suggestion thread is about making the lfse tool more efficient, so i'll never understand reactionnary (opposed to change) comments like those that want to explain you the tricks to circumvent the inefficiency of that tool. Just plain non sense.
@ivo_drifta i dont understand the point of ur comment,
even if it has been improved with the click + drag, it still remains a uselessly painfull and time consuming process.
didnt read everything back so it may already have been suggested and i missed it
polygon selection by angle threshold would help assigning those smoothing groups, wich is a painfull and long process when importing models built on other 3d modelers.
something like this :
click one poly, set angle threshold, click some "select by angle" button, and editor would select all adjacent polys with a normal angle difference below the threshold.
ex : if threshold is set to zero, all adjacent polys on the same plan (a flat surface) are selected.
Threshold should have at least one digit precision ex: 15.7
Customizable engine and flywheel weight would be a great addition,
we could have those aluminium parts at last.
Maybe wheels (rims) too, it that makes sense.
hey rob2003
If I read u well, Insim wouldnt have needed any update since first version of the MCI packet.
Maybe u dont see the point of hacking because something blocks your view, or maybe u just not curious... a few tools using mem access like steerlock or templock have been very popular for a reason.
Anyway for rev limiters, switching ignition via Insim by sending keyboard input has already been done a few times in the past and it's always been terrible because that method is much too slow to achieve a convincing result.
While I agree the topic is sensitive and can bring havoc like it already did, I have never been satisfied with Insim as a way to access car data, and this for 2 main reasons :
- too few data things available via Insim.
For years I wanted to access fuel level to check for cheating, because it's so easy to change that value in memory and cheat races without being noticed, specially endurance. Now you added it in Insim and people can make code to check fuel usage and expose bad guys, that's good ok.
It would be usefull for example to get access to tyre temps, tyre wear or clutch wear because those are as easy as fuel level to tamper with.
- for a local app, like "revbouncer" for example, the issue with Insim is the complexity of the code for network communication compared to direct memory access (at least for me), and also the lower access speed with network, wich is a major issue for a responsive ignition cut rev limiter (ability to ignition cut without mem access is another example missing from Insim).
Maybe something like an API would be nice, we could even overlay graphics easily with it.
Am not writing that mem access should be supported at all, this just a perspective from someone who spent some years exploring lfs code and mechanics, with passion and love, because hacking is like solving a scientific problem or a criminal investigation.
I learned a lot with it and I didnt release anything that would allow cheating so it's not always bad.
On a side note : you do great job again, but please clone yourself or teach Scawen Jr. so he can help
truly an amazing quality work, wow
however, it could be even more jaw dropping if you used "vertex shading" option (when u select a point in modeller, just below "center point"), specially inside the cockpit like footwell.
that option is rarely used and it's a waste because its a simple way to add depth in rendering.
Also engine sound could be refined.
Well, dont misunderstand, it's a gem, but it has potential to be a crown jewel
It is very possible to upshift or downshift without clutch in a real car. I used to drive like this a lot, and still do cause am lazy. The thing is : its not fuel efficient, and slower than using clutch on a normal (slow to rev up/down) engine.
well i found how to clean up those bad normals.
Now I remember, in my case the bad normals were created this way :
- imagine a box with one side exactly on the left/right mirroring axis
- when i mirror that box, the face adjacent to the mirror axis is duplicated, at the same place, but flipped,
This is the case of the first example u dscribe scawen : 2 faces, pointing opposite directions and sharing same edges, created by mirroring.
Now i fixed this by simply manually deleting those faces, ok.
I realize that this is actually one of the basic modelling issue in 3d, and on my 3d software, I have a function to remove those polygons. It's called "unify", and by one click it will cleanup those particular polygons by removing the one wich normal is not aligned with the adjacent ones.
It is quite usefull, because those polys are sometime very tricky to find.
We also have a mirror function, wich automatically cleans up things on the mirroring axis.
Regarding small triangles, to me 1 square millimeter area is negligible detail, or even could be seen as a modelling mistake, wich would warrant an automatic fuse/merge to simplify geometry.
edit: We also have a function to select 1 and 2 points polygons wich can be created in multiplying operations (like mirror), then we can easily remove those polys.
isnt there a way to automatically fix them bad normals ?
I remember importing a model I built with another software, the model was clean, then I did some simple operation in Editor (i forgot wich) and it created many bad normal points, wich i dont know how to clean now.
For AI driving, it would help to have an option to manually recompute the AI path, as most of times when a mod is updated, the path is not automatically recomputed, even when suspension geometry, weight and other critical things are changed.
As it is now, we have to manually delete the file in data/knw/ to trigger a recompute.
edit:
also when I want the AI to race a mod on "super" compound tyres, if that mod has slicks on default setup, the path generation will be done with slicks, not my setup, even if the "AI uses player setup" option is set.
Then AI races on normals with a path for slicks, and misses almost every corner.
It would be good that path generation could be computed with player setup.
as mbutcher writes, it is quite easy to spot most cheating hacks, anything giving above 0.5% more torque, grip, aero etc is directly spotable, and below those values the benefits are discutable, unless maybe if it makes sense for a top driver to get 0.01% advantage on others, wich i dont believe, because if not detectable on the spot, the replay will speak.
Also since version 0.7, there is no more dedi server available, and uncommon hacks are now impossible or quite harder to get working. That said, there are still some holes that may worth a fix, specially in endurance racing, i wont reveal them here obviously, but i can give detailed infos to trusty people if needed.
@cuni
yes but that is only guidelines (12h, 7d, 30d, perm), some exceptions can happen regarding ban length
@federal_br
log states it is your first ban, and as i couldnt talk with the admin who banned you, i have some doubts he made a mistake, so u are unbanned from now, but please keep it as clean as possible when are back on server.
This sounds like a very unlikely "problem". If it happens, it would be 1 mod over 1000 ?
Makes me wonder if your post is an intended joke.
Let's remember Scawen is a developper, he can program quite anything, that's what programming is about.
it would be usefull to be able to sort mods by power/weight ratio, tyre compound, weight, power, wings
then we could much more conveniently find matching cars for improvised racing, or filter allowed cars on server.
as it is now, it requires a lot of time to browse and read those numbers for almost each mod, and the "class" filter is not quite relevant enough.
The original model is published under CC-BY license, so yes, u can change whatever u want in it, add new things, change shapes/geometry, anything, as long as u credit the original author.
I love that truck btw, it handles like I expect a heavy truck to do. Good job. Dont spoil it : )