[DiscordArchive] materials are defined in the root though so it doesn't matter ?
[DiscordArchive] materials are defined in the root though so it doesn't matter ?
Original source
materials are defined in the root though so it doesn't matter ?
rektbyfaith
09-28-2023, 09:46 PM #1Archived author: Titi • Posted: 2023-09-28T21:46:53.267000+00:00
Original source
materials are defined in the root though so it doesn't matter ?
Original source
ohh, now I see my mistake
rektbyfaith
09-28-2023, 09:48 PM #2Archived author: MeFisto94 • Posted: 2023-09-28T21:48:02.475000+00:00
Original source
ohh, now I see my mistake
Original source
thanks for the batches hint
rektbyfaith
09-28-2023, 09:48 PM #3Archived author: MeFisto94 • Posted: 2023-09-28T21:48:06.932000+00:00
Original source
thanks for the batches hint
Original source
I haven't read until the MOBA chunk but instead been using the MOPY chunk directly
rektbyfaith
09-28-2023, 09:48 PM #4Archived author: MeFisto94 • Posted: 2023-09-28T21:48:22.179000+00:00
Original source
I haven't read until the MOBA chunk but instead been using the MOPY chunk directly
Original source
I mean there's not too much difference between using the batches to split meshes and finding which verts had unique material_ids, but that at least makes it more reasonable, from the design perspective
rektbyfaith
09-28-2023, 09:48 PM #5Archived author: MeFisto94 • Posted: 2023-09-28T21:48:55.686000+00:00
Original source
I mean there's not too much difference between using the batches to split meshes and finding which verts had unique material_ids, but that at least makes it more reasonable, from the design perspective
Original source
less calculation at runtime
rektbyfaith
09-28-2023, 09:57 PM #6Archived author: Titi • Posted: 2023-09-28T21:57:10.946000+00:00
Original source
less calculation at runtime
Original source
true. It probably iterates over the batches and issues a render call while keeping the same buffers bound. Probably because the binding overhead is larger than those (relatively small) buffers. Not sure how well I can translate this to modern, simple APIs <:think:961618249273970709>
rektbyfaith
09-28-2023, 10:04 PM #7Archived author: MeFisto94 • Posted: 2023-09-28T22:04:37.240000+00:00
Original source
true. It probably iterates over the batches and issues a render call while keeping the same buffers bound. Probably because the binding overhead is larger than those (relatively small) buffers. Not sure how well I can translate this to modern, simple APIs <:think:961618249273970709>
Original source
"modern" "simple"
rektbyfaith
09-28-2023, 10:06 PM #8Archived author: Titi • Posted: 2023-09-28T22:06:02.486000+00:00
Original source
"modern" "simple"
Original source
2005 opengl was surely 500x simpler than current graphics API
rektbyfaith
09-28-2023, 10:06 PM #9Archived author: Titi • Posted: 2023-09-28T22:06:29.636000+00:00
Original source
2005 opengl was surely 500x simpler than current graphics API
Original source
yep, but the engines abstract away much more nowadays. I think I remember seeing some DX Apis with DrawIndirect that took counts and start/offsets, but that is rather kept away. At least in this engine I am currently using, it even asserts that all vertex buffers conform to the "vertex length" being passed for it's mesh class
rektbyfaith
09-28-2023, 10:10 PM #10Archived author: MeFisto94 • Posted: 2023-09-28T22:10:37.109000+00:00
Original source
yep, but the engines abstract away much more nowadays. I think I remember seeing some DX Apis with DrawIndirect that took counts and start/offsets, but that is rather kept away. At least in this engine I am currently using, it even asserts that all vertex buffers conform to the "vertex length" being passed for it's mesh class
1 Guest(s)
1 Guest(s)